From: Irena J. <ijo...@pp...> - 2014-08-27 14:41:46
|
Hi Arjen, Yes, this worked! I was now able to compile and install plplot for pgf-13.6. Thank you very much for your help! -- Irena On Wed, Aug 27, 2014 at 10:02 AM, Arjen Markus <Arj...@de...> 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...> > 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...] > *Sent:* Wednesday, August 27, 2014 2:43 PM > *To:* Alan W. Irwin > *Cc:* 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...> > 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 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). > > 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 > __________________________ > > > > 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. > |