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:ijohn...@pppl.gov]
Sent: Wednesday, August 27, 2014 3:55 PM
To: Arjen Markus
Cc: Alan W. Irwin; plplot-general@lists.sourceforge.net
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 
<arjen.mar...@deltares.nl<mailto:arjen.mar...@deltares.nl>> 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:ijohn...@pppl.gov<mailto:ijohn...@pppl.gov>]
Sent: Wednesday, August 27, 2014 2:43 PM
To: Alan W. Irwin
Cc: 
plplot-general@lists.sourceforge.net<mailto:plplot-general@lists.sourceforge.net>
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...@beluga.phys.uvic.ca<mailto:ir...@beluga.phys.uvic.ca>> 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
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general

Reply via email to