From: Irena J. <ijo...@pp...> - 2014-08-27 14:45:43
|
Hi Davide, OK, thanks for the info. It might be good to try the newer version of pgi-13, but we have a lot of customized software here for our scientists and sometimes they require a specific version of a compiler. $ pgfortran --version pgfortran 13.6-0 64-bit target on x86-64 Linux -tp k8e Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. Copyright 2000-2013, STMicroelectronics, Inc. All Rights Reserved. Thanks, --Irena On Wed, Aug 27, 2014 at 10:15 AM, Davide Cesari <dc...@ar...> wrote: > 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 > ======================================================================== > > > ------------------------------------------------------------------------------ > 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 > -- Irena |