On 2016-05-09 18:50-0000 Arjen Markus wrote: > Hi Wadud, > > > >> -----Original Message----- >> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] >> >> 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 __________________________ ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
