Re: [Plplot-devel] PLplot Fortran bindings

[Alan W. I. <ir...@be...>]

On 2016-05-09 18:50-0000 Arjen Markus wrote:

> Hi Wadud,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>>
>> Hi Wadud:
>>
>> Thanks very much for your build test of PLplot using the NAG Fortran compiler.
>>
>> ... >
>> To investigate further why the above logic unexpectedly cannot be compiled with
>> the NAG compiler, I strongly suggest you make a small one-file example containing
>> a simplified plplot_types module that just defines private_plflt, and plcGrid exactly
>> like we do, and which also contains another module that includes the above
>> subroutine transform.
>> Then if that vastly simplified example also fails to compile you have that example to
>> take to the NAG developers concerning a possible bug in their compiler.  Or they
>> may respond to your report by saying something like this: "to get that Fortran
>> standards compliant code to compile with the NAG compiler, you need xxx flag".
>>
>
>
> I prepared a small example (see below) that is generously accepted by the two compilers I have access to. I think it exhibits the characteristics of the code that is not accepted by the NAG compiler. The only difference that may be important is the fact that it does not contain the ISO_C_BINDING features. If this small example is accepted, then I would say it is indeed a problem in the NAG compiler.
>
> The alternative is that the example is not accepted and that the NAG compiler doesn't like the import through the nesting of interfaces. I would not think that the example is non-standard, but there can be subtleties that I am overlooking here. That is why it is important to see what the NAG compiler comes up with.
>
> Regards,
>
> Arjen
>
> ! nested_interface.f90 --
>
> !     Attempt to reproduce a problem discovered by Wadud Miah
>
> !
>
> module my_types
>
>    implicit none
>
>
>
>    type xyz
>
>        integer :: x, y, z
>
>    end type xyz
>
> end module my_types
>
>
>
> module my_interfaces
>
>    use my_types
>
>
>
>    implicit none
>
>
>
>    interface
>
>        subroutine use_transform( transform )
>
>            interface
>
>                subroutine transform( data, result )
>
>                    import :: xyz
>
>                    type(xyz) :: data
>
>                    real      :: result
>
>                end subroutine transform
>
>            end interface
>
>        end subroutine use_transform
>
>    end interface
>
> end module my_interfaces

Hi Arjen:

You are absolutely right to ask Wadud to try the above simplest possible
example of importing a type from another module first.

However, another potential issue here is that if the NAG Fortran compiler
compiles

import :: private_plflt, PLcGrid

from left to right, then it had no problem with importing
plflt_private which is a type defined in a very similar manner to
PLcGrid.

So if Wadud verifies the above simple one-type example compiles for the NAG
fortran compiler, then you will likely want to make your example more
complex using two simple types just in case the NAG Fortran compiler
issue is with more than one imported type.  Then if that simple
two-type case has no NAG problem, try using our exact types for
private_plflt and PLcGrid instead.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________