From: Davide C. <dc...@ar...> - 2014-08-27 14:30:41
|
Hi Irena and Arjen, just to add some information: I have Fortran PGI compiler available, version 13.10 [dcesari@malina ~]$ pgfortran --version pgfortran 13.10-0 64-bit target on x86-64 Linux -tp p7 The Portland Group - PGI Compilers and Tools Copyright (c) 2013, NVIDIA CORPORATION. All rights reserved. and it seems that it is capable to compile successfully both Arjen code excerpt as well as the complete sfstubsf95.f90 extracted from git together with the dependencies, can we compare the versions? I almost stopped using PGI because it tends to fail on many correct pieces of code even sticking to strict f90 standard, however some bugs are fixed from time to time. Davide On 27/08/2014 16:02, Arjen Markus wrote: > Hi Irena, > > Odd, the only thing I can think of is that the compiler does not like > this combination of a module procedure and an explicit interface block. > Could you try with: > > interface plsvect > > module procedure plsvect1 > > end interface > > interface plsvect > > subroutine plsvect2 > > end subroutine plsvect2 > > end interface > > (Change it directly in the file sfstubs95.f90) > > You can specify multiple interfaces with the same name as long as the > individual routines can be distinguished > > If this does not work either, it is time for me to consult the > comp.lang.fortran group. > > Regards, > > Arjen > > *From:*Irena Johnson [mailto:ijo...@pp...] > *Sent:* Wednesday, August 27, 2014 3:55 PM > *To:* Arjen Markus > *Cc:* Alan W. Irwin; plp...@li... > *Subject:* Re: [Plplot-general] continuation lines in > bindings/tcl/plplot_parameters.h > > Hi Arjen, > > I am getting the same error: > > $ pgf95 -g -Minfo=all -v ../dummy.f90 > > /usr/pppl/pgi/13.6/linux86-64/13.6/bin/pgf901 ../dummy.f90 -debug -x 120 > 0x200 -opt 0 -inform inform -nohpf -nostatic -tp k8e -x 19 0x400000 > -quad -x 59 4 -x 59 4 -x 15 2 -x 49 0x400004 -x 51 0x20 -x 57 0x4c -x 58 > 0x10000 -x 124 0x1000 -x 57 0xfb0000 -x 58 0x78031040 -x 48 4608 -x 49 > 0x100 -x 120 0x200 -stdinc > /usr/pppl/pgi/13.6/linux86-64/13.6/include:/usr/local/include:/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include:/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include:/usr/include > -def unix -def __unix -def __unix__ -def linux -def __linux -def > __linux__ -def __NO_MATH_INLINES -def __x86_64 -def __x86_64__ -def > __LONG_MAX__=9223372036854775807L -def '__SIZE_TYPE__=unsigned long int' > -def '__PTRDIFF_TYPE__=long int' -def __THROW= -def __extension__= -def > __amd_64__amd64__ -def __k8 -def __k8__ -def __SSE__ -def __MMX__ -def > __SSE2__ -def __SSE3__ -freeform -vect 48 -y 54 1 -x 70 0x40000000 -x 49 > 0x1000 -modexport /tmp/pgf95QGsb_y8X0eLt.cmod -modindex > /tmp/pgf956GsbUGFEBSoq.cmdx -output /tmp/pgf95AGsboF4nTv5R.ilm > > *PGF90-S-0070-Incorrect sequence of statements* (../dummy.f90: 7) > > 0 inform, 0 warnings, 1 severes, 0 fatal for dummy > > 0 inform, 0 warnings, 0 severes, 0 fatal for plsvect1 > > PGF90/x86-64 Linux 13.6-0: compilation completed with severe errors > > pgf95-Fatal-f901 completed with exit code 1 > > From http://www.pgroup.com/doc/pghpf_ug/hpfug12.htm, > > *S 70 "Incorrect sequence of statements $"* > > The statement order is incorrect. For instance, an IMPLICIT NONE > statement must precede a specification statement which in turn must > precede an executable statement. > > Thanks, > > --Irena > > On Wed, Aug 27, 2014 at 9:21 AM, Arjen Markus <Arj...@de... > <mailto:Arj...@de...>> wrote: > > Hi Irena, > > That is rather odd, the code is correct as far as I can tell. Could you > try to compile this code: > > module dummy > > interface plsvect > > module procedure plsvect1 > > subroutine plsvect2 > > end subroutine plsvect2 > > end interface > > contains > > subroutine plsvect1( x ) > > real :: x > > end subroutine plsvect1 > > end module dummy > > This should be perfectly acceptable code. If not, the PG compiler is > doing something odd. Can you use a flag that will tell us more about > what is wrong according to the compiler? > > Regards, > > Arjen > > *From:*Irena Johnson [mailto:ijo...@pp... <mailto:ijo...@pp...>] > *Sent:* Wednesday, August 27, 2014 2:43 PM > *To:* Alan W. Irwin > *Cc:* plp...@li... > <mailto:plp...@li...> > *Subject:* Re: [Plplot-general] continuation lines in > bindings/tcl/plplot_parameters.h > > Hi Alan, plplot_parameters.h > > Thank you for your help with this issue: I got the latest version of > plplot from git and your modification to plplot_parameters.h has worked!! > > Unfortunately, the compiler now fails with "PGF90-S-0070-Incorrect > sequence of statements" > > [ 24%] Built target plplotf95c > > Scanning dependencies of target plplotf95 > > [ 25%] Building Fortran object > bindings/f95/CMakeFiles/plplotf95.dir/strutil.f90.o > > [ 25%] Building Fortran object > bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o > > PGF90-S-0070-Incorrect sequence of statements > (/pfs/tmp/ijohnson/plplot.git/bindings/f95/sfstubsf95.f90: 905) > > 0 inform, 0 warnings, 1 severes, 0 fatal for plplot > > make[3]: *** [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o] > Error 2 > > make[2]: *** > [bindings/f95/CMakeFiles/plplotf95.dir/sfstubsf95.f90.o.provides] Error 2 > > make[1]: *** [bindings/f95/CMakeFiles/plplotf95.dir/all] Error 2 > > make: *** [all] Error 2 > > Thank you, > > --Irena > > On Tue, Aug 26, 2014 at 7:00 PM, Alan W. Irwin > <ir...@be... <mailto:ir...@be...>> wrote: > > On 2014-08-26 13:21-0700 Alan W. Irwin wrote: > > Getting back to the principal issue, it appears to me that gcc is > accepting all those "\n\" continuation lines in > bindings/tcl/plplot_parameters.h, but your Portland Group compiler is > not. We will look further at this. > > Hi Irena: > > I have now changed the style of plplot_parameters.h to replace one huge > string > literal by a large number of small string literals that the compiler > should automatically concatenate together. > > I prefer this new style on general principles, and gcc compiles this > style just as well as the old style. It's possible your Portland Group > compiler will still choke on this style as it attempts to concatenate > those string literals together. But on the other hand, it might work. > > To test that possibility, please try the latest version of our > source code using > > git clone git://git.code.sf.net/p/plplot/plplot > <http://git.code.sf.net/p/plplot/plplot> plplot.git > > Then try your normal build (with -DENABLE_tcl=ON or else by removing > -DENABLE_tcl=OFF from the cmake command line since ENABLE_tcl is ON by > default) referring to this version of the source tree rather than > 5.10.0 and starting from an empty build tree. If your compiler is > able to compile bindings/tcl/tclAPI.c without issues, then the change in > style > should be judged a success. > > Furthermore, I hope your set of Portland Group compilers is able to > finish the rest of a default build of PLplot without issues, but if > there are such issues we will try to deal with them since we prefer to > have PLplot builds be successful on all compilers and not just gcc. > > By the way, I think the above is the first reference to our new > official git repository on this list (although there has been a large > amount of traffic about this huge change in PLplot development on the > plplot-devel list). The short story is our svn repository at SF is > now frozen in read-only mode and as of a few days ago we switched to > using git for PLplot development with the above being our official git > repo. I am pretty much a git newbie myself, but my use of it for the > last several days shows it is an extremely popular version control > system for good reasons. Therefore, I think there is an excellent > chance this change from subversion to git will not only help our > current set of developers but also attract new developers to the > project. > > > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca > <http://astrowww.phys.uvic.ca>). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net > <http://freeeos.sf.net>); the Time > Ephemerides project (timeephem.sf.net <http://timeephem.sf.net>); PLplot > scientific plotting > software package (plplot.sf.net <http://plplot.sf.net>); the libLASi project > (unifont.org/lasi <http://unifont.org/lasi>); the Loads of Linux Links > project (loll.sf.net <http://loll.sf.net>); > and the Linux Brochure Project (lbproject.sf.net <http://lbproject.sf.net>). > __________________________ > > Linux-powered Science > __________________________ > > DISCLAIMER: This message is intended exclusively for the addressee(s) > and may contain confidential and privileged information. If you are not > the intended recipient please notify the sender immediately and destroy > this message. Unauthorized use, disclosure or copying of this message is > strictly prohibited. The foundation 'Stichting Deltares', which has its > seat at Delft, The Netherlands, Commercial Registration Number 41146461, > is not liable in any way whatsoever for consequences and/or damages > resulting from the improper, incomplete and untimely dispatch, receipt > and/or content of this e-mail. > > > > DISCLAIMER: This message is intended exclusively for the addressee(s) > and may contain confidential and privileged information. If you are not > the intended recipient please notify the sender immediately and destroy > this message. Unauthorized use, disclosure or copying of this message is > strictly prohibited. The foundation 'Stichting Deltares', which has its > seat at Delft, The Netherlands, Commercial Registration Number 41146461, > is not liable in any way whatsoever for consequences and/or damages > resulting from the improper, incomplete and untimely dispatch, receipt > and/or content of this e-mail. > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > > > > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general > -- ============================= Davide Cesari ============================ Dott**(0.5) Davide Cesari ARPA-Emilia Romagna, Servizio IdroMeteoClima NWP modelling - Modellistica numerica previsionale Tel. +39 051525926 ======================================================================== |