From: Alan W. I. <ir...@be...> - 2011-10-07 23:28:41
|
Hi Andrew: Following Geoffrey's recent advice to test our software for standards compliancy, I tried the following: export CFLAGS='-O3 -fvisibility=hidden -std=c99 -pedantic' export 'CXXFLAGS='-O3 -fvisibility=hidden -std=c++98 -pedantic' export FFLAGS='-O3' cmake -DENABLE_java=OFF ... make test_noninteractive The results for that test without java had no obvious errors, but there were lots of warning messages during the compilation about our code not being compliant with standards. That is a big concern so I hope you will take a look at these warning messages to see what can be done. Also, if I enable java, then starting with a fresh build and compiling with the above CFLAGS values generates a segfault on the first java example with either the test_noninteractive or test_java_psc targets. Could you also take a look at that related issue? If I try the java build with the above CXXFLAGS and FFLAGS, but with export CFLAGS='-O3 -fvisibility=hidden' then there are no obvious errors or build warnings with the test_java_psc or test_noninteractive targets. If my remaining tests using the above CXXFLAGS and FFLAGS, and export CFLAGS='-O3 -fvisibility=hidden' work okay on Linux, and other Windows, Mac OS X, and Linux tests look okay, then I anticipate that we will be able to go ahead with a quick release of 5.9.9 from PLplot svn trunk this weekend to deal with the Windows broken build issues for 5.9.8 in a timely manner. So we should not do anything about the -std=c99 situation before that quick release, but after that I think it is important to bring our code into compliance with the c99 standard. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2011-10-08 00:46:03
|
On 2011-10-07 16:28-0700 Alan W. Irwin wrote: > Hi Andrew: > > Following Geoffrey's recent advice to test our software for standards > compliancy, I tried the following: > > export CFLAGS='-O3 -fvisibility=hidden -std=c99 -pedantic' > export 'CXXFLAGS='-O3 -fvisibility=hidden -std=c++98 -pedantic' > export FFLAGS='-O3' > > cmake -DENABLE_java=OFF ... > > make test_noninteractive > > The results for that test without java had no obvious errors, but > there were lots of warning messages during the compilation about our > code not being compliant with standards. That is a big concern so I > hope you will take a look at these warning messages to see what can > be done. > > Also, if I enable java, then starting with a fresh build and compiling > with the above CFLAGS values generates a segfault on the first java > example with either the test_noninteractive or test_java_psc targets. > > Could you also take a look at that related issue? > > If I try the java build with the above CXXFLAGS and FFLAGS, but with > > export CFLAGS='-O3 -fvisibility=hidden' > > then there are no obvious errors or build warnings with the test_java_psc or > test_noninteractive targets. Actually, I got ahead of myself there, and in fact there are lots of build warnings about C++ non-standards compliancy in this case as well. So my further tests (until you can figure this out post release) will be with export CFLAGS='-O3 -fvisibility=hidden' export CXXFLAGS='-O3 -fvisibility=hidden' export FFLAGS='-O3' 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 __________________________ |
From: Andrew R. <and...@us...> - 2011-10-08 14:56:07
|
On Fri, Oct 07, 2011 at 05:45:56PM -0700, Alan Irwin wrote: > On 2011-10-07 16:28-0700 Alan W. Irwin wrote: > > > Hi Andrew: > > > > Following Geoffrey's recent advice to test our software for standards > > compliancy, I tried the following: > > > > export CFLAGS='-O3 -fvisibility=hidden -std=c99 -pedantic' > > export 'CXXFLAGS='-O3 -fvisibility=hidden -std=c++98 -pedantic' > > export FFLAGS='-O3' > > > > cmake -DENABLE_java=OFF ... > > > > make test_noninteractive > > > > The results for that test without java had no obvious errors, but > > there were lots of warning messages during the compilation about our > > code not being compliant with standards. That is a big concern so I > > hope you will take a look at these warning messages to see what can > > be done. > > > > Also, if I enable java, then starting with a fresh build and compiling > > with the above CFLAGS values generates a segfault on the first java > > example with either the test_noninteractive or test_java_psc targets. > > > > Could you also take a look at that related issue? > > > > If I try the java build with the above CXXFLAGS and FFLAGS, but with > > > > export CFLAGS='-O3 -fvisibility=hidden' > > > > then there are no obvious errors or build warnings with the test_java_psc or > > test_noninteractive targets. > > Actually, I got ahead of myself there, and in fact there are lots of > build warnings about C++ non-standards compliancy in this case as well. > > So my further tests (until you can figure this out post release) will be with > > export CFLAGS='-O3 -fvisibility=hidden' > export CXXFLAGS='-O3 -fvisibility=hidden' > export FFLAGS='-O3' Alan, I'll add it to my list. Currently rather snowed under with work. I urgently need to update the Debian packages. This will be next priority. Andrew |
From: Alan W. I. <ir...@be...> - 2011-10-21 00:09:03
|
On 2011-10-20 15:23+0100 Andrew Ross wrote: > Gcc with no standards flags is now warning free again. Thanks, Andrew, for those changes which did solve the broken build for export CFLAGS='-O3 -fvisibility=hidden' export CXXFLAGS='-O3 -fvisibility=hidden' export FFLAGS='-O3' on my platform. Furthermore, "ctest -j8" completed with no errors. However, there are 3 similar build warnings still left on my platform which are as follows: In file included from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/qt.h:72, from /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/c++/qt_PlotWindow.h:39, from /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/c++/qt_example.cpp:26: /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/plplotP.h:273:1: warning: "isfinite" redefined In file included from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/plplotP.h:111, from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/qt.h:72, from /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/c++/qt_PlotWindow.h:39, from /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/c++/qt_example.cpp:26: /usr/include/math.h:245:1: warning: this is the location of the previous definition In file included from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/qt.h:72, from /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/c++/qt_PlotWindow.h:39, from /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/c++/qt_PlotWindow.cpp:26: /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/plplotP.h:273:1: warning: "isfinite" redefined In file included from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/plplotP.h:111, from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/qt.h:72, from /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/c++/qt_PlotWindow.h:39, from /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/c++/qt_PlotWindow.cpp:26: /usr/include/math.h:245:1: warning: this is the location of the previous definition In file included from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/qt.h:72, from /home/software/plplot_svn/HEAD/build_dir/examples/c++/../../../plplot_cmake_qt/examples/c++/qt_PlotWindow.h:39, from /home/software/plplot_svn/HEAD/build_dir/examples/c++/moc_qt_PlotWindow.cxx:10: /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/plplotP.h:273:1: warning: "isfinite" redefined In file included from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/plplotP.h:111, from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/qt.h:72, from /home/software/plplot_svn/HEAD/build_dir/examples/c++/../../../plplot_cmake_qt/examples/c++/qt_PlotWindow.h:39, from /home/software/plplot_svn/HEAD/build_dir/examples/c++/moc_qt_PlotWindow.cxx:10: /usr/include/math.h:245:1: warning: this is the location of the previous definition The relevant lines from math.h on my platform are as follows: /* Return nonzero value if X is not +-Inf or NaN. */ # ifdef __NO_LONG_DOUBLE_MATH # define isfinite(x) \ (sizeof (x) == sizeof (float) ? __finitef (x) : __finite (x)) # else # define isfinite(x) \ (sizeof (x) == sizeof (float) \ ? __finitef (x) \ : sizeof (x) == sizeof (double) \ ? __finite (x) : __finitel (x)) # endif line 245 is just after the #else so apparently my system does have long double math. 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 __________________________ |
From: José L. G. P. <jgp...@gm...> - 2011-10-21 08:02:57
|
Hello, I put here different sets of compiler flags for many different compilers. Some of them are not free software, but I think that can be used by someone in order to check a clean compilation for them. I've tried that the flags (when exist) were equivalent to the used gcc ones: Free compilares: GCC: ------- gcc -std=c99 -pedantic -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wnested-externs -Wconversion -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings CLANG: ---------- clang -std=c99 -pedantic -Wextra-tokens OPENWATCOM (OWCC): --------------------------------- owcc -std=c99 -Wall -Wextra -Woverlay OPEN64 (OPENCC): -------------------------- opencc -std=c99 -pedantic -Wall -Wbad-function-cast -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wdiv-by-zero -Wunreachable-code -Wunused -Wunused-parameter -Wwrite-strings -Wconversion -Wformat-nonliteral -Wformat-security -Wmissing-noreturn -Wpointer-arith -Wredundant-decls -Wshadow -Wsign-compare -Wswitch-enum PATHSCALE (PATHCC): ------------------------------ pathcc -std=c99 -Wall -Wmissing-prototypes -Wstrict-prototypes -Wnested-externs -Wconversion -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings MERCURIUM (PLAINCC): -------------------------------- plaincc -std=c99 -Wall -Wextra -Wconversion -Wmissing-prototypes -Wstrict-prototypes -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings -Wnested-externs TCC: -------- tcc -Wall -Wunsupported -Wwrite-strings PCC: ------- pcc NWCC: --------- nwcc -pedantic Non free compilers INTEL (ICC): ---------------- pathcc -std=c99 -Wall -Wmissing-prototypes -Wstrict-prototypes -Wnested-externs -Wconversion -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings ORACLE (SUNCC): ------------------------- suncc -xc99=all -Xc -xCC -errfmt -errhdr -xbuiltin -xlibmil -xlibmopt -errtags -v PORTLAND GROUP (PGCC): -------------------------------------- pgcc -c99 -Minform=warn LCC: ------- lcc -A -A Cheers -- ***************************************** José Luis García Pallero jgp...@gm... (o< / / \ V_/_ Use Debian GNU/Linux and enjoy! ***************************************** |
From: José L. G. P. <jgp...@gm...> - 2011-10-08 15:57:49
|
2011/10/8 Andrew Ross <and...@us...>: > On Fri, Oct 07, 2011 at 05:45:56PM -0700, Alan Irwin wrote: >> On 2011-10-07 16:28-0700 Alan W. Irwin wrote: >> >> > Hi Andrew: >> > >> > Following Geoffrey's recent advice to test our software for standards >> > compliancy, I tried the following: >> > >> > export CFLAGS='-O3 -fvisibility=hidden -std=c99 -pedantic' >> > export 'CXXFLAGS='-O3 -fvisibility=hidden -std=c++98 -pedantic' >> > export FFLAGS='-O3' In gcc documentation it can be readed about the -pedantic flag (http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Warning-Options.html#Warning-Options): "Some users try to use -pedantic to check programs for strict ISO C conformance. They soon find that it does not do quite what they want: it finds some non-ISO practices, but not all—only those for which ISO C requires a diagnostic, and some others for which diagnostics have been added." So I think that other warning flags should be added in order to check the warning (not only warnongs concerning c99). First of all I think that -Wall and -Wextra could be added. But -Wall and -Wextra do not detect some warnings that I consider important, as type conversion (useful to detect, for example, signed assignation to an unsigned variable) or missing prototypes of functions. My list of flags for c99 compilation is: CFLAGS='-O3 -std=c99 -pedantic -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wnested-externs -Wconversion -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings' >> > >> > cmake -DENABLE_java=OFF ... >> > >> > make test_noninteractive >> > >> > The results for that test without java had no obvious errors, but >> > there were lots of warning messages during the compilation about our >> > code not being compliant with standards. That is a big concern so I >> > hope you will take a look at these warning messages to see what can >> > be done. >> > >> > Also, if I enable java, then starting with a fresh build and compiling >> > with the above CFLAGS values generates a segfault on the first java >> > example with either the test_noninteractive or test_java_psc targets. >> > >> > Could you also take a look at that related issue? >> > >> > If I try the java build with the above CXXFLAGS and FFLAGS, but with >> > >> > export CFLAGS='-O3 -fvisibility=hidden' >> > >> > then there are no obvious errors or build warnings with the test_java_psc or >> > test_noninteractive targets. >> >> Actually, I got ahead of myself there, and in fact there are lots of >> build warnings about C++ non-standards compliancy in this case as well. >> >> So my further tests (until you can figure this out post release) will be with >> >> export CFLAGS='-O3 -fvisibility=hidden' >> export CXXFLAGS='-O3 -fvisibility=hidden' >> export FFLAGS='-O3' > > Alan, > > I'll add it to my list. Currently rather snowed under with work. I > urgently need to update the Debian packages. This will be next > priority. > > Andrew > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2dcopy2 > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > -- ***************************************** José Luis García Pallero jgp...@gm... (o< / / \ V_/_ Use Debian GNU/Linux and enjoy! ***************************************** |
From: Alan W. I. <ir...@be...> - 2011-10-08 18:44:18
|
On 2011-10-08 17:57+0200 José Luis García Pallero wrote: > 2011/10/8 Andrew Ross <and...@us...>: >> On Fri, Oct 07, 2011 at 05:45:56PM -0700, Alan Irwin wrote: >>> On 2011-10-07 16:28-0700 Alan W. Irwin wrote: >>> >>>> Hi Andrew: >>>> >>>> Following Geoffrey's recent advice to test our software for standards >>>> compliancy, I tried the following: >>>> >>>> export CFLAGS='-O3 -fvisibility=hidden -std=c99 -pedantic' >>>> export 'CXXFLAGS='-O3 -fvisibility=hidden -std=c++98 -pedantic' >>>> export FFLAGS='-O3' > > In gcc documentation it can be readed about the -pedantic flag > (http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Warning-Options.html#Warning-Options): > > "Some users try to use -pedantic to check programs for strict ISO C > conformance. They soon find that it does not do quite what they want: > it finds some non-ISO practices, but not all—only those for which ISO > C requires a diagnostic, and some others for which diagnostics have > been added." > > So I think that other warning flags should be added in order to check > the warning (not only warnongs concerning c99). First of all I think > that -Wall and -Wextra could be added. But -Wall and -Wextra do not > detect some warnings that I consider important, as type conversion > (useful to detect, for example, signed assignation to an unsigned > variable) or missing prototypes of functions. My list of flags for c99 > compilation is: > > CFLAGS='-O3 -std=c99 -pedantic -Wall -Wextra -Wmissing-prototypes > -Wstrict-prototypes -Wnested-externs -Wconversion -Wshadow -Wcast-qual > -Wcast-align -Wwrite-strings' Hi José: Thanks very much for your advice which I think is quite good, but there will necessarily be a bit of delay adopting it. We are in the midst of a lot of testing looking primarily for any recently introduced regressions in preparation for a quick release to deal with the showstopper Windows build issues for 5.9.8 that have just been revealed to us. After that release we plan to deal with the many issues already revealed by "-std=c99 -pedantic". Once those are dealt with, I plan to take your advice and see what more is revealed by all the flags above. So I put the above flags in my testing scripts, but I commented them out for now. 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 __________________________ |
From: José L. G. P. <jgp...@gm...> - 2011-10-08 19:19:08
|
El día 8 de octubre de 2011 20:44, Alan W. Irwin <ir...@be...> escribió: > On 2011-10-08 17:57+0200 José Luis García Pallero wrote: > >> 2011/10/8 Andrew Ross <and...@us...>: >>> >>> On Fri, Oct 07, 2011 at 05:45:56PM -0700, Alan Irwin wrote: >>>> >>>> On 2011-10-07 16:28-0700 Alan W. Irwin wrote: >>>> >>>>> Hi Andrew: >>>>> >>>>> Following Geoffrey's recent advice to test our software for standards >>>>> compliancy, I tried the following: >>>>> >>>>> export CFLAGS='-O3 -fvisibility=hidden -std=c99 -pedantic' >>>>> export 'CXXFLAGS='-O3 -fvisibility=hidden -std=c++98 -pedantic' >>>>> export FFLAGS='-O3' >> >> In gcc documentation it can be readed about the -pedantic flag >> >> (http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Warning-Options.html#Warning-Options): >> >> "Some users try to use -pedantic to check programs for strict ISO C >> conformance. They soon find that it does not do quite what they want: >> it finds some non-ISO practices, but not all—only those for which ISO >> C requires a diagnostic, and some others for which diagnostics have >> been added." >> >> So I think that other warning flags should be added in order to check >> the warning (not only warnongs concerning c99). First of all I think >> that -Wall and -Wextra could be added. But -Wall and -Wextra do not >> detect some warnings that I consider important, as type conversion >> (useful to detect, for example, signed assignation to an unsigned >> variable) or missing prototypes of functions. My list of flags for c99 >> compilation is: >> >> CFLAGS='-O3 -std=c99 -pedantic -Wall -Wextra -Wmissing-prototypes >> -Wstrict-prototypes -Wnested-externs -Wconversion -Wshadow -Wcast-qual >> -Wcast-align -Wwrite-strings' > > Hi José: > > Thanks very much for your advice which I think is quite good, but > there will necessarily be a bit of delay adopting it. We are in the > midst of a lot of testing looking primarily for any recently > introduced regressions in preparation for a quick release to deal with > the showstopper Windows build issues for 5.9.8 that have just been > revealed to us. After that release we plan to deal with the many > issues already revealed by "-std=c99 -pedantic". Once those are dealt > with, I plan to take your advice and see what more is revealed by all > the flags above. So I put the above flags in my testing scripts, but > I commented them out for now. Hello, Some of my warnings flags are the same as the GSL recommends. Here are commented in more detail: http://www.gnu.org/s/gsl/manual/html_node/GCC-warning-options-for-numerical-programs.html > > 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 > __________________________ > -- ***************************************** José Luis García Pallero jgp...@gm... (o< / / \ V_/_ Use Debian GNU/Linux and enjoy! ***************************************** |
From: Alan W. I. <ir...@be...> - 2011-10-08 18:45:59
|
On 2011-10-08 15:55+0100 Andrew Ross wrote: >>> If I try the java build with the above CXXFLAGS and FFLAGS, but with >>> >>> export CFLAGS='-O3 -fvisibility=hidden' >>> >>> then there are no obvious errors or build warnings with the test_java_psc or >>> test_noninteractive targets. >> >> Actually, I got ahead of myself there, and in fact there are lots of >> build warnings about C++ non-standards compliancy in this case as well. >> >> So my further tests (until you can figure this out post release) will be with >> >> export CFLAGS='-O3 -fvisibility=hidden' >> export CXXFLAGS='-O3 -fvisibility=hidden' >> export FFLAGS='-O3' > > Alan, > > I'll add it to my list. Currently rather snowed under with work. I > urgently need to update the Debian packages. This will be next > priority. Understood, and thanks for putting this on your ToDo list. 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 __________________________ |
From: Andrew R. <and...@us...> - 2011-10-21 08:45:55
|
On Thu, Oct 20, 2011 at 05:08:50PM -0700, Alan Irwin wrote: > On 2011-10-20 15:23+0100 Andrew Ross wrote: > > > Gcc with no standards flags is now warning free again. > > Thanks, Andrew, for those changes which did solve the broken build for > > export CFLAGS='-O3 -fvisibility=hidden' > export CXXFLAGS='-O3 -fvisibility=hidden' > export FFLAGS='-O3' > > on my platform. Furthermore, "ctest -j8" completed with no errors. > > However, there are 3 similar build warnings still left on my platform which are > as follows: > > In file included from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/qt.h:72, > from /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/c++/qt_PlotWindow.h:39, > from /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/c++/qt_example.cpp:26: > /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/plplotP.h:273:1: warning: "isfinite" redefined > In file included from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/plplotP.h:111, > from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/qt.h:72, > from /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/c++/qt_PlotWindow.h:39, > from /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/c++/qt_example.cpp:26: > /usr/include/math.h:245:1: warning: this is the location of the previous definition > > In file included from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/qt.h:72, > from /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/c++/qt_PlotWindow.h:39, > from /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/c++/qt_PlotWindow.cpp:26: > /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/plplotP.h:273:1: warning: "isfinite" redefined > In file included from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/plplotP.h:111, > from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/qt.h:72, > from /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/c++/qt_PlotWindow.h:39, > from /home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/c++/qt_PlotWindow.cpp:26: > /usr/include/math.h:245:1: warning: this is the location of the previous definition > > In file included from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/qt.h:72, > from /home/software/plplot_svn/HEAD/build_dir/examples/c++/../../../plplot_cmake_qt/examples/c++/qt_PlotWindow.h:39, > from /home/software/plplot_svn/HEAD/build_dir/examples/c++/moc_qt_PlotWindow.cxx:10: > /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/plplotP.h:273:1: warning: "isfinite" redefined > In file included from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/plplotP.h:111, > from /home/software/plplot_svn/HEAD/plplot_cmake_qt/include/qt.h:72, > from /home/software/plplot_svn/HEAD/build_dir/examples/c++/../../../plplot_cmake_qt/examples/c++/qt_PlotWindow.h:39, > from /home/software/plplot_svn/HEAD/build_dir/examples/c++/moc_qt_PlotWindow.cxx:10: > /usr/include/math.h:245:1: warning: this is the location of the previous definition > > The relevant lines from math.h on my platform are as follows: > > /* Return nonzero value if X is not +-Inf or NaN. */ > # ifdef __NO_LONG_DOUBLE_MATH > # define isfinite(x) \ > (sizeof (x) == sizeof (float) ? __finitef (x) : __finite (x)) > # else > # define isfinite(x) \ > (sizeof (x) == sizeof (float) \ > ? __finitef (x) \ > : sizeof (x) == sizeof (double) \ > ? __finite (x) : __finitel (x)) > # endif > > line 245 is just after the #else so apparently my system does have long > double math. I'd independently spotted this doing the same test as you. The problem is that the "internal" plplotP.h header is actually used indirectly in the qt examples. In this case HAVE_CONFIG_H is not set to some of the defines (e.g. the check for isfinite) are missing. It is similar to the problem I fixed yesteday with ocamlc not setting HAVE_CONFIG_H. I've moved the required defines to plConfig.h to solve the problem. It would be nice though if plplotP.h was truly internal. In my opinion this should just be used for the build. It is not part of the API and so ideally we shouldn't need to expose the user to it or install it. I've done some further testing on another system with a newer version of gcc and this has exposed some further warnings. In particular it is now much more picky about const for 2-d arrays, i.e. pointers to pointers The problem is that we make use of things like const PLFLT **a. The says that a is a pointer to an array of pointers which in turn point to arrays of PLFLT. The const says that the arrays of PLFLT are constant, but NOT that the array of pointers is constant. It is therefore trivial to change the pointers in order to change the underlying data. This undermines the const guarantee. Strictly one would usually want to do something like const PLFLT * const *a which guarantees that both the PLFLT arrays and the PLFLT * array are constant. This leads to quite ugly definitions though. Invariably const specifiers in C are quite pervasive. Once you have made something const it has to propogate through subsequent function calls. Fixing these warnings is likely to result in API changes to the contouring / shading functions which use const PLFLT **. The code ugliness and clarity could probably be addressed using some typedefs. E.g. something like typedef (const PLFLT * const *) PLFLT_array2D_const; The real question is, "Is this worth it for a potentially pervasive API change just to fix compiler warnings?" Another issue I've encountered is that PLplot makes a fair bit of use of casting function pointers to PLpointer (i.e. void *) for passing between functions. This contravenes ISO C as there is no guarantee that function pointers and object pointers have the same size. In practice they do, which is why the code works, but we might want to consider a cleaner way of doing this. Again this is a potential API change, but it is a clear contravention of standards as opposed to just a compiler warning. I have had no response to my previous email about handling unused parameter values. I take that as assent to my proposals, so I will try implementing the UNUSED macro approach, at least for the core library code in src/ . Once there is a concrete implementation in place people might be in a better position to comment. I realise this is a lot of questions, but given that fixing these issues might involve API changes I wanted to seek some sort of consensus, or at least give people the chance to comment, before making any changes. Andrew |
From: Andrew R. <and...@us...> - 2011-10-11 14:57:56
|
On Sat, Oct 08, 2011 at 11:45:52AM -0700, Alan Irwin wrote: > On 2011-10-08 15:55+0100 Andrew Ross wrote: > > >>> If I try the java build with the above CXXFLAGS and FFLAGS, but with > >>> > >>> export CFLAGS='-O3 -fvisibility=hidden' > >>> > >>> then there are no obvious errors or build warnings with the test_java_psc or > >>> test_noninteractive targets. > >> > >> Actually, I got ahead of myself there, and in fact there are lots of > >> build warnings about C++ non-standards compliancy in this case as well. > >> > >> So my further tests (until you can figure this out post release) will be with > >> > >> export CFLAGS='-O3 -fvisibility=hidden' > >> export CXXFLAGS='-O3 -fvisibility=hidden' > >> export FFLAGS='-O3' > > > > Alan, > > > > I'll add it to my list. Currently rather snowed under with work. I > > urgently need to update the Debian packages. This will be next > > priority. > > Understood, and thanks for putting this on your ToDo list. I have taken an initial look at this. It's a whole can of worms! Firstly, I can reproduce your java crashes with openjdk or sun jdk but not with gcj. This is a little odd. The backtraces are not entirely helpful but it appears to be related to fprintf calls in the C part of the bindings. It is also not entirely reproducible, i.e. the same example won't segfault every time. A better start is probably to work through the huge number of compiler warnings. Aside from the java issues there are a number of other issues I encountered. Several parts of plplot use features which are POSIX standard, but not part of the 1999 ISO C standard. strdup is one example, also some of the signal handling in xwin / tk drivers. The latter is not an issue since these drivers are only available on Unix like systems anyway. This just makes it a pain to compile since either we add compiler defines to allow posix features for the whole compile (not ideal) or we need to add specific compile flags for specific files which is not too easy in cmake (at least not in a quick and dirty way). FFLAGS is used for both f77 and f95 compiles which makes it hard to tailor the flags for different standards. Again, it is a limitation of cmakes handling of these things. In terms of the warnings themeselves, there are a lot related to implicit casting of int / uint / size_t. We can make this clean either by being consistent about types (best, but intrusive) or by explicit casting (which hides the problem! - but in most cases we know it is ok anyway). There are also warnings about assigning constant strings to non-const char * arrays. On the whole changing to const char * fixes this and is relatively straightforward. We don't always use prototypes for functions. Again, this is relatively easy to fix if we feel it is serious enough. It is probably good form to do so anyway. Unused parameters appear in a fair number of places. In function definitions I would tend to leave these in for clarity, even if they are not strictly necessary. Possibly uninitialized variables also appear. In all the cases I've looked at they were actually ok, but were defined inside some if ... else ... statements which the compiler cannot analyse to check they are set. Probably good form to set them explicitly to some default / null value to avoid future problems. The recent issue Alan found with qsastime is a good example of this. A number of external libraries we use (e.g. wxwidgets, cairo, python) have headers which are not clean. A favourite seems to be using "long long" which is not in ISO C++ 1998. Hard to do much about this. SWIG generated code is not very clean, which again might be tricky to deal with. Lots of examples of local variables shadowing a global variable or typedef. Probably safe, but generally not good practice. So, in short there are some possible real issues and a fair bit of noise. I've started some work tidying up bits of the code, but I certainly won't commit anything until after the next release as it is going to be pretty intrusive. Once I've cleaned up the easy parts, we can discuss what to do about the more tricky warnings. Andrew |
From: Andrew R. <and...@us...> - 2011-10-21 12:06:16
|
On Fri, Oct 21, 2011 at 09:45:47AM +0100, Andrew Ross wrote: > > I'd independently spotted this doing the same test as you. > > The problem is that the "internal" plplotP.h header is actually used > indirectly in the qt examples. In this case HAVE_CONFIG_H is not set to > some of the defines (e.g. the check for isfinite) are missing. It is > similar to the problem I fixed yesteday with ocamlc not setting > HAVE_CONFIG_H. I've moved the required defines to plConfig.h to solve the > problem. It would be nice though if plplotP.h was truly internal. In my > opinion this should just be used for the build. It is not part of the API > and so ideally we shouldn't need to expose the user to it or install it. > > I've done some further testing on another system with a newer version of > gcc and this has exposed some further warnings. In particular it is > now much more picky about const for 2-d arrays, i.e. pointers to pointers > The problem is that we make use of things like const PLFLT **a. The says > that a is a pointer to an array of pointers which in turn point to arrays > of PLFLT. The const says that the arrays of PLFLT are constant, but NOT > that the array of pointers is constant. It is therefore trivial to > change the pointers in order to change the underlying data. This undermines > the const guarantee. Strictly one would usually want to do something like > const PLFLT * const *a which guarantees that both the PLFLT arrays and > the PLFLT * array are constant. This leads to quite ugly definitions though. > Invariably const specifiers in C are quite pervasive. Once you have made > something const it has to propogate through subsequent function calls. > > Fixing these warnings is likely to result in API changes to the contouring > / shading functions which use const PLFLT **. The code ugliness and > clarity could probably be addressed using some typedefs. E.g. > something like > > typedef (const PLFLT * const *) PLFLT_array2D_const; > > The real question is, "Is this worth it for a potentially > pervasive API change just to fix compiler warnings?" > > Another issue I've encountered is that PLplot makes a fair bit of use > of casting function pointers to PLpointer (i.e. void *) for passing > between functions. This contravenes ISO C as there is no > guarantee that function pointers and object pointers have the same > size. In practice they do, which is why the code works, but we might > want to consider a cleaner way of doing this. Again this is a potential > API change, but it is a clear contravention of standards as opposed to > just a compiler warning. I've managed to avoid all of these in the PLplot code through better use of casts. There still exist a couple of examples related to external libraries (notably calls to lt_dlsym), but there is little we can do about that. > I have had no response to my previous email about handling unused parameter > values. I take that as assent to my proposals, so I will try implementing > the UNUSED macro approach, at least for the core library code in src/ . > Once there is a concrete implementation in place people might be in a > better position to comment. I've now implemented this for src/plargs.c as a file with a lot of unused parameters. Please look at, test and comment on the implementation. > I realise this is a lot of questions, but given that fixing these > issues might involve API changes I wanted to seek some sort of > consensus, or at least give people the chance to comment, before > making any changes. Andrew |
From: Andrew R. <and...@us...> - 2011-10-28 13:04:41
|
On Fri, Oct 21, 2011 at 01:06:08PM +0100, Andrew Ross wrote: > On Fri, Oct 21, 2011 at 09:45:47AM +0100, Andrew Ross wrote: > > > > I have had no response to my previous email about handling unused parameter > > values. I take that as assent to my proposals, so I will try implementing > > the UNUSED macro approach, at least for the core library code in src/ . > > Once there is a concrete implementation in place people might be in a > > better position to comment. > > I've now implemented this for src/plargs.c as a file with a lot of > unused parameters. Please look at, test and comment on the implementation. Since no-one has protested, I've gone ahead and started to roll this out more widely. I've renamed the macro to PL_UNUSED to avoid potential namespace clashes, and moved it to plplot.h. This means we can use it in the examples as well. This has removed a large number of the remaining warnings. Alan: I've noticed one issue that you might want to look at. The file bindings/tcl/plplot_parameters.h is generated by a sed script. It creates a large string of commands to pass to the tcl interpreter. Unfortunately the length of this string (currently 5296) is greater than the string length which compilers are required to support under the ISO C99 standard (4096 characters). The length is even less for C89. I don't know whether any compilers enforce this limit, but it would be prudent to avoid this long static string. Possibilities include splitting it up into several smaller strings, or dynamically allocating the string (can be any size) and then copying in the commands in smaller chunks. I've also changed how this header is included slightly. Since it is a static function copies were being included in a number of object files which didn't actually use the function. Andrew |
From: Alan W. I. <ir...@be...> - 2011-10-28 18:40:26
|
Hi Andrew: I am going to pass this decision about the correct way to avoid that long string over to Arjen. See below. On 2011-10-28 14:04+0100 Andrew Ross wrote: > Alan: I've noticed one issue that you might want to look at. The file > bindings/tcl/plplot_parameters.h is generated by a sed script. It > creates a large string of commands to pass to the tcl interpreter. > Unfortunately the length of this string (currently 5296) is greater > than the string length which compilers are required to support under > the ISO C99 standard (4096 characters). The length is even less for > C89. I don't know whether any compilers enforce this limit, but > it would be prudent to avoid this long static string. Possibilities > include splitting it up into several smaller strings, or dynamically > allocating the string (can be any size) and then copying in the > commands in smaller chunks. I've also changed how this header is > included slightly. Since it is a static function copies were being > included in a number of object files which didn't actually use > the function. Hi Arjen: bindings/tcl/plplot_parameters.h was your original creation so could you have a look at it to see how to reformat it to avoid the long string that violates C standards that Andrew referred to above? I am involved in this to a certain extent because I am the author of the custom target called check_tcl_parameters (see bindings/tcl/CMakeLists.txt). That target uses the "sed" command to process the #defines in bindings/swig-support/plplotcapi.i to create a check version called bindings/tcl/plplot_parameters.h_compare in the build tree. It then uses the "cmp" command to check the consistency between that check version and bindings/tcl/plplot_parameters.h. Just now I made some changes in bindings/tcl/global_defines.sed so that it produces styled results. Therefore as of revision 12013 the check_tcl_parameters target generates a check version that is in exact agreement with our already existing styled version of bindings/tcl/plplot_parameters.h. By the way, I adopted this method of checking bindings/tcl/plplot_parameters.h for consistency rather than simply generating that file, because not all platforms have access to sed. Note, that once you decide on the appropriate format for bindings/tcl/plplot_parameters.h to avoid the long string, there should be no necessity for hand crafting bindings/tcl/plplot_parameters.h. Instead, please let me know what format you desire, and I can do the rest with the appropriate changes to the sed script and copying the resulting bindings/tcl/plplot_parameters.h_compare back to bindings/tcl/plplot_parameters.h. Alternatively, you do have access to both the sed and cmp commands via MSYS. So you have the opportunity of changing the sed script yourself, running the check_tcl_parameters target, and looking at the resulting bindings/tcl/plplot_parameters.h_compare to make sure it has your desired format. I could help you with the sed part of this if your sed knowledge is a little rusty (or currently nonexistent). 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 __________________________ |
From: Arjen M. <arj...@de...> - 2011-10-31 07:36:40
|
Hi Alan, sure, I will have a look, though I do not have time within the first couple of days of this week. Regards, Arjen On 2011-10-28 20:40, Alan W. Irwin wrote: > Hi Andrew: > > I am going to pass this decision about the correct way to > avoid that long string over to Arjen. See below. > > On 2011-10-28 14:04+0100 Andrew Ross wrote: > >> Alan: I've noticed one issue that you might want to look at. The file >> bindings/tcl/plplot_parameters.h is generated by a sed script. It >> creates a large string of commands to pass to the tcl interpreter. >> Unfortunately the length of this string (currently 5296) is greater >> than the string length which compilers are required to support under >> the ISO C99 standard (4096 characters). The length is even less for >> C89. I don't know whether any compilers enforce this limit, but >> it would be prudent to avoid this long static string. Possibilities >> include splitting it up into several smaller strings, or dynamically >> allocating the string (can be any size) and then copying in the >> commands in smaller chunks. I've also changed how this header is >> included slightly. Since it is a static function copies were being >> included in a number of object files which didn't actually use >> the function. > > Hi Arjen: > > bindings/tcl/plplot_parameters.h was your original creation so could > you have a look at it to see how to reformat it to avoid the > long string that violates C standards that Andrew referred to above? > > I am involved in this to a certain extent because I am the author of > the custom target called check_tcl_parameters (see > bindings/tcl/CMakeLists.txt). That target uses the "sed" command to > process the #defines in bindings/swig-support/plplotcapi.i to create a > check version called bindings/tcl/plplot_parameters.h_compare in the > build tree. It then uses the "cmp" command to check the consistency > between that check version and bindings/tcl/plplot_parameters.h. Just > now I made some changes in bindings/tcl/global_defines.sed so that it > produces styled results. Therefore as of revision 12013 the > check_tcl_parameters target generates a check version that is in exact > agreement with our already existing styled version of > bindings/tcl/plplot_parameters.h. > > By the way, I adopted this method of checking > bindings/tcl/plplot_parameters.h for consistency rather than simply > generating that file, because not all platforms have access to sed. > > Note, that once you decide on the appropriate format for > bindings/tcl/plplot_parameters.h to avoid the long string, there > should be no necessity for hand crafting > bindings/tcl/plplot_parameters.h. Instead, please let me know what > format you desire, and I can do the rest with the appropriate changes > to the sed script and copying the resulting > bindings/tcl/plplot_parameters.h_compare back to > bindings/tcl/plplot_parameters.h. > > Alternatively, you do have access to both the sed and cmp commands via > MSYS. So you have the opportunity of changing the sed script > yourself, running the check_tcl_parameters target, and looking at the > resulting bindings/tcl/plplot_parameters.h_compare to make sure it has > your desired format. I could help you with the sed part of this if > your sed knowledge is a little rusty (or currently nonexistent). > > 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. |
From: Andrew R. <and...@us...> - 2011-10-14 07:26:10
|
On Tue, Oct 11, 2011 at 03:57:43PM +0100, Andrew Ross wrote: > > I have taken an initial look at this. It's a whole can of worms! > > Firstly, I can reproduce your java crashes with openjdk or sun jdk but > not with gcj. This is a little odd. The backtraces are not entirely > helpful but it appears to be related to fprintf calls in the C part of > the bindings. It is also not entirely reproducible, i.e. the same > example won't segfault every time. A better start is probably to work > through the huge number of compiler warnings. > > Aside from the java issues there are a number of other issues I > encountered. Several parts of plplot use features which are POSIX > standard, but not part of the 1999 ISO C standard. strdup is one > example, also some of the signal handling in xwin / tk drivers. The > latter is not an issue since these drivers are only available on Unix > like systems anyway. This just makes it a pain to compile since either > we add compiler defines to allow posix features for the whole compile > (not ideal) or we need to add specific compile flags for specific files > which is not too easy in cmake (at least not in a quick and dirty way). > > FFLAGS is used for both f77 and f95 compiles which makes it hard to > tailor the flags for different standards. Again, it is a limitation > of cmakes handling of these things. > > In terms of the warnings themeselves, there are a lot related to > implicit casting of int / uint / size_t. We can make this clean > either by being consistent about types (best, but intrusive) or > by explicit casting (which hides the problem! - but in most cases > we know it is ok anyway). > > There are also warnings about assigning constant strings to non-const > char * arrays. On the whole changing to const char * fixes this and is > relatively straightforward. > > We don't always use prototypes for functions. Again, this is relatively > easy to fix if we feel it is serious enough. It is probably good form > to do so anyway. > > Unused parameters appear in a fair number of places. In function > definitions I would tend to leave these in for clarity, even if they > are not strictly necessary. > > Possibly uninitialized variables also appear. In all the cases I've > looked at they were actually ok, but were defined inside some > if ... else ... statements which the compiler cannot analyse to > check they are set. Probably good form to set them explicitly to > some default / null value to avoid future problems. The recent issue > Alan found with qsastime is a good example of this. > > A number of external libraries we use (e.g. wxwidgets, cairo, python) > have headers which are not clean. A favourite seems to be using "long long" > which is not in ISO C++ 1998. Hard to do much about this. > > SWIG generated code is not very clean, which again might be tricky to > deal with. > > Lots of examples of local variables shadowing a global variable or > typedef. Probably safe, but generally not good practice. > > So, in short there are some possible real issues and a fair bit of noise. > I've started some work tidying up bits of the code, but I certainly won't > commit anything until after the next release as it is going to be pretty > intrusive. Once I've cleaned up the easy parts, we can discuss what to > do about the more tricky warnings. I've committed the first tranche of fixes for compiler warnings. For reference I've been testing with CFLAGS="-O3 -std=c99 -pedantic -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wnested-externs -Wconversion -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings" CCFLAGS=-O3 -fvisibility=hidden -std=c++98 -pedantic -Wall -Wextra FFLAGS=-O3 -fvisibility=hidden -pedantic -Wall -Wextra When required I have (by hand) added -D_POSIX_C_SOURCE=1 to the flags for specific files (e.g. xwin.c) in order to compile. So far this is just the easy to fix issues (function prototypes, missing braces, missing const for char *, shadowed variables, unused functions.) This is quite intrusive, so please test well. There will be more to come. So far I've not even looked at the issues related to casting variables between different types or at fortran. If someone with more fortran insight wants to take that on it would be good. I've also not looked at the java issue. Andrew |
From: Alan W. I. <ir...@be...> - 2011-10-14 08:37:40
|
On 2011-10-14 08:26+0100 Andrew Ross wrote: > I've committed the first tranche of fixes for compiler warnings. > > For reference I've been testing with > CFLAGS="-O3 -std=c99 -pedantic -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wnested-externs -Wconversion -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings" > CCFLAGS=-O3 -fvisibility=hidden -std=c++98 -pedantic -Wall -Wextra > FFLAGS=-O3 -fvisibility=hidden -pedantic -Wall -Wextra > > When required I have (by hand) added -D_POSIX_C_SOURCE=1 to the flags for > specific files (e.g. xwin.c) in order to compile. > > So far this is just the easy to fix issues (function prototypes, missing > braces, missing const for char *, shadowed variables, unused functions.) > This is quite intrusive, so please test well. Ordinary compile flags CXXFLAGS=-O3 -fvisibility=hidden CFLAGS=-O3 -fvisibility=hidden FFLAGS=-O3 now give the following warning: /home/software/plplot_svn/HEAD/plplot_cmake_qt/src/plargs.c: In function ‘ProcessOpt’: /home/software/plplot_svn/HEAD/plplot_cmake_qt/src/plargs.c:1119: warning: assignment discards qualifiers from pointer target type which wasn't there before. Other than that as of revision 11970 (my style changes on top of your compiler warning fixes up to just before that revision), ctest -j4 shows no obvious issues. By the way, I just discovered that "parallel test" option -j4 really does speed ctest execution on a machine with two physical processors. > There will be more to come. Good work, Andrew! 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2011-12-07 18:05:11
|
Hi Andrew: Some time ago in connection with the Time Ephmerides project I built the Debian unstable gcc-4.6 packages (version 4.6.1-13) on my Debian stable platform to get access to gfortran quadruple precision. These compilers are not suitable for comprehensive testing of PLplot because they don't include Ada and D so I have not used them before for that purpose, but out of curiosity today I did some limited testing (just the test_noninteractive target in the build tree) for the following environment variables: CC=gcc-4.6 CXX=g++-4.6 FC=gfortran-4.6 CFLAGS=-O3 -fvisibility=hidden CXXFLAGS=-O3 -fvisibility=hidden FFLAGS=-O3 and the following cmake options: -DBUILD_TEST=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON \ -DENABLE_f95=ON -DENABLE_f77=ON As expected, the result was no compiler warnings and no run-time errors for the test_noninteractive target in the build tree. What do you now recommend for CFLAGS, CXXFLAGS, and FFLAGS for the most rigourous code-quality testing for the above compilers? 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 __________________________ |
From: Andrew R. <and...@us...> - 2011-12-08 19:46:09
|
Alan, My recommended settings following the discussion on the list are documented in README.release. I've been using CFLAGS='-O3 -std=c99 -pedantic -D_POSIX_C_SOURCE=200112L -Wall \ -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wnested-externs \ -Wconversion -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings' CXXFLAGS='-O3 -fvisibility=hidden -std=c++98 -pedantic -Wall -Wextra ' FFLAGS='-std=f95 -O3 -fall-intrinsics -fvisibility=hidden -pedantic \ -Wall -Wextra ' Andrew On Wed, Dec 07, 2011 at 10:05:04AM -0800, Alan Irwin wrote: > Hi Andrew: > > Some time ago in connection with the Time Ephmerides project I built > the Debian unstable gcc-4.6 packages (version 4.6.1-13) on my Debian > stable platform to get access to gfortran quadruple precision. These > compilers are not suitable for comprehensive testing of PLplot because > they don't include Ada and D so I have not used them before for that > purpose, but out of curiosity today I did some limited testing (just > the test_noninteractive target in the build tree) for the following > environment variables: > > CC=gcc-4.6 > CXX=g++-4.6 > FC=gfortran-4.6 > CFLAGS=-O3 -fvisibility=hidden > CXXFLAGS=-O3 -fvisibility=hidden > FFLAGS=-O3 > > and the following cmake options: > > -DBUILD_TEST=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON \ > -DENABLE_f95=ON -DENABLE_f77=ON > > As expected, the result was no compiler warnings and no run-time errors > for the test_noninteractive target in the build tree. > > What do you now recommend for CFLAGS, CXXFLAGS, and FFLAGS for the most > rigourous code-quality testing for the above compilers? > > 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 > __________________________ > > ------------------------------------------------------------------------------ > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist and point of > discussion for anyone considering optimizing the pricing and packaging model > of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ir...@be...> - 2011-10-17 19:15:03
|
@Arjen: There is a question for you at the end concerning deprecating/retiring our f77 bindings and examples. On 2011-10-14 08:26+0100 Andrew Ross wrote: [...] >> FFLAGS is used for both f77 and f95 compiles which makes it hard to >> tailor the flags for different standards. Again, it is a limitation >> of cmakes handling of these things. [...] > FFLAGS=-O3 -fvisibility=hidden -pedantic -Wall -Wextra [...] > So far I've not even looked at [...] fortran. If someone with more fortran > insight wants to take that on it would be good. Hi Andrew: In connection with a different project I have just looked at the -std capability of gfortran, and it makes for interesting reading: <quote from info gfortran> `-std=STD' Specify the standard to which the program is expected to conform, which may be one of `f95', `f2003', `f2008', `gnu', or `legacy'. The default value for STD is `gnu', which specifies a superset of the Fortran 95 standard that includes all of the extensions supported by GNU Fortran, although warnings will be given for obsolete extensions not recommended for use in new code. The `legacy' value is equivalent but without the warnings for obsolete extensions, and may be useful for old non-standard programs. The `f95', `f2003' and `f2008' values specify strict conformance to the Fortran 95, Fortran 2003 and Fortran 2008 standards, respectively; errors are given for all extensions beyond the relevant language standard, and warnings are given for the Fortran 77 features that are permitted but obsolescent in later standards. </quote> So gfortran has no support for a strict Fortran 77 standard. That's probably okay. My experience with strict Fortran 77 is it is a real pain to use; historically there were a lot of extremely useful extensions to that standard for VAX/VMS Fortran that became a pseudo-standard themselves. It is that pseudo-standard that I have tended to use over the years for the "Fortran 77+" scientific libraries and applications that I have implemented so it is likely that my contributions to our standard f77 examples includes those language extensions. So given the state of legacy fortran support in gfortran, here is what I think you should do. * Do your initial Fortran tests with f77 disabled. This should allow you to use -std=f95 to weed out any problematic code in our f95 bindings and examples. * Finish by enabling f77 and using -std=legacy. This is a pretty weak test since it does not discriminate in the slightest against pure Fortran 95 code getting into our f77 bindings and examples, but I think you should perform this test just in case it discovers some "Fortran 77" code that is problematic in general. * At some point I think we should deprecate and then retire the f77 bindings and examples. A lot of the scientific libraries and applications I implemented over the years were written in "Fortran 77+", and my knowledge of modern Fortran is still pretty shaky. Nevertheless, even I can see that the Fortran 9x and 20xx changes were a long-overdue revolutionary change to Fortran 77 that has turned Fortran into an extremely powerful and interesting language. So I am not sure how much longer it would be worthwhile for us to put any effort into our f77 bindings and examples when there is a lot of interesting things we could be doing with our f95 bindings and examples instead. @Arjen: I would be extremely interested in your take on this matter since you probably have the best knowlege here of the overall state of Fortran. Also, since you are the guy that has been maintaining our f77 bindings and examples I think the decision about when to deprecate/retire these bindings and examples is strictly your call. Nevertheless, I do suggest you at least consider the matter in terms of cost of maintaining those f77 bindings/examples versus the benefit to our users. The key part of that analysis is your best guess at whether there are still substantial numbers of Fortran users out there who still prefer using our f77 rather than f95 bindings and examples. My guess is there are not, but I trust your guess more than mine. :-) 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 __________________________ |
From: Arjen M. <arj...@de...> - 2011-10-18 07:19:35
|
Hi Alan, On 2011-10-17 21:14, Alan W. Irwin wrote: > @Arjen: There is a question for you at the end concerning > deprecating/retiring our f77 bindings and examples. > > > So gfortran has no support for a strict Fortran 77 standard. That's > probably okay. My experience with strict Fortran 77 is it is a real > pain to use; historically there were a lot of extremely useful > extensions to that standard for VAX/VMS Fortran that became a > pseudo-standard themselves. It is that pseudo-standard that I have > tended to use over the years for the "Fortran 77+" scientific > libraries and applications that I have implemented so it is > likely that my contributions to our standard f77 examples includes > those language extensions. > > So given the state of legacy fortran support in gfortran, here is what > I think you should do. > > * Do your initial Fortran tests with f77 disabled. This should allow > you to use -std=f95 to weed out any problematic code in our f95 bindings > and examples. > > * Finish by enabling f77 and using -std=legacy. This is a pretty > weak test since it does not discriminate in the slightest against pure > Fortran 95 code getting into our f77 bindings and examples, but I > think you should perform this test just in case it discovers some > "Fortran 77" code that is problematic in general. > > * At some point I think we should deprecate and then retire the f77 > bindings and examples. A lot of the scientific libraries and > applications I implemented over the years were written in "Fortran > 77+", and my knowledge of modern Fortran is still pretty shaky. > Nevertheless, even I can see that the Fortran 9x and 20xx changes were > a long-overdue revolutionary change to Fortran 77 that has turned > Fortran into an extremely powerful and interesting language. So I am > not sure how much longer it would be worthwhile for us to put any > effort into our f77 bindings and examples when there is a lot of > interesting things we could be doing with our f95 bindings and > examples instead. > > @Arjen: I would be extremely interested in your take on this matter > since you probably have the best knowlege here of the overall state of > Fortran. Also, since you are the guy that has been maintaining our f77 > bindings and examples I think the decision about when to > deprecate/retire these bindings and examples is strictly your call. > Nevertheless, I do suggest you at least consider the matter in terms > of cost of maintaining those f77 bindings/examples versus the benefit > to our users. The key part of that analysis is your best guess at > whether there are still substantial numbers of Fortran users out there > who still prefer using our f77 rather than f95 bindings and examples. > My guess is there are not, but I trust your guess more than mine. :-) > The only pure FORTRAN 77 compiler that might still be in wide use, as far as I can tell, is g77. This compiler has not been maintained for quite a few years now. gfortran supports most if not all popular extensions to the FORTRAN 77 standards that g77 supports/supported. If you want to test for strict FORTRAN 77 compliance, then g77 is the only option. However, many people still use that standard, that is, they do not use the newer features. Since the FORTRAN 77 standard is an almost strict subset of the Fortran 90/95/2003/2008 standards, those programs continue to work. (There are some minor exceptions, such as the use of REAL variables to control a do-loop, but compilers will likely continue to support them for the coming years.) That said, I think we could at least announce that we intend to turn off the F77 bindings in the next release, with an indication that the F95 bindings are the preferred set. Regards, Arjen 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. |
From: Andrew R. <and...@us...> - 2011-10-19 14:49:06
|
On Mon, Oct 17, 2011 at 12:14:56PM -0700, Alan Irwin wrote: > @Arjen: There is a question for you at the end concerning > deprecating/retiring our f77 bindings and examples. > > On 2011-10-14 08:26+0100 Andrew Ross wrote: > > [...] > >> FFLAGS is used for both f77 and f95 compiles which makes it hard to > >> tailor the flags for different standards. Again, it is a limitation > >> of cmakes handling of these things. > [...] > > FFLAGS=-O3 -fvisibility=hidden -pedantic -Wall -Wextra > [...] > > So far I've not even looked at [...] fortran. If someone with more fortran > > insight wants to take that on it would be good. > > Hi Andrew: > > In connection with a different project I have just looked at the -std > capability of gfortran, and it makes for interesting reading: > > <quote from info gfortran> > `-std=STD' > Specify the standard to which the program is expected to conform, > which may be one of `f95', `f2003', `f2008', `gnu', or `legacy'. > The default value for STD is `gnu', which specifies a superset of > the Fortran 95 standard that includes all of the extensions > supported by GNU Fortran, although warnings will be given for > obsolete extensions not recommended for use in new code. The > `legacy' value is equivalent but without the warnings for obsolete > extensions, and may be useful for old non-standard programs. The > `f95', `f2003' and `f2008' values specify strict conformance to > the Fortran 95, Fortran 2003 and Fortran 2008 standards, > respectively; errors are given for all extensions beyond the > relevant language standard, and warnings are given for the Fortran > 77 features that are permitted but obsolescent in later standards. > </quote> > > So gfortran has no support for a strict Fortran 77 standard. That's > probably okay. My experience with strict Fortran 77 is it is a real > pain to use; historically there were a lot of extremely useful > extensions to that standard for VAX/VMS Fortran that became a > pseudo-standard themselves. It is that pseudo-standard that I have > tended to use over the years for the "Fortran 77+" scientific > libraries and applications that I have implemented so it is > likely that my contributions to our standard f77 examples includes > those language extensions. > > So given the state of legacy fortran support in gfortran, here is what > I think you should do. > > * Do your initial Fortran tests with f77 disabled. This should allow > you to use -std=f95 to weed out any problematic code in our f95 bindings > and examples. > > * Finish by enabling f77 and using -std=legacy. This is a pretty > weak test since it does not discriminate in the slightest against pure > Fortran 95 code getting into our f77 bindings and examples, but I > think you should perform this test just in case it discovers some > "Fortran 77" code that is problematic in general. > > * At some point I think we should deprecate and then retire the f77 > bindings and examples. A lot of the scientific libraries and > applications I implemented over the years were written in "Fortran > 77+", and my knowledge of modern Fortran is still pretty shaky. > Nevertheless, even I can see that the Fortran 9x and 20xx changes were > a long-overdue revolutionary change to Fortran 77 that has turned > Fortran into an extremely powerful and interesting language. So I am > not sure how much longer it would be worthwhile for us to put any > effort into our f77 bindings and examples when there is a lot of > interesting things we could be doing with our f95 bindings and > examples instead. > > @Arjen: I would be extremely interested in your take on this matter > since you probably have the best knowlege here of the overall state of > Fortran. Also, since you are the guy that has been maintaining our f77 > bindings and examples I think the decision about when to > deprecate/retire these bindings and examples is strictly your call. > Nevertheless, I do suggest you at least consider the matter in terms > of cost of maintaining those f77 bindings/examples versus the benefit > to our users. The key part of that analysis is your best guess at > whether there are still substantial numbers of Fortran users out there > who still prefer using our f77 rather than f95 bindings and examples. > My guess is there are not, but I trust your guess more than mine. :-) I've done this and the f95 bindings are now compliant with the f95 standard apart from 1) The iargc and getarg intrinsics which are used to get command line arguments. These are a gnu extension. Fortran 2003 does include different intrinsics for getting command line arguments. We probably should support these in the long term, but no idea whether current compilers adhere to that standard. 2) The flush intrinsic in example 14. This is another gnu extension to f95. Again fortran 2003 includes a flush function with the same capabilities so updating our target fortran version would fix this. I had to rework a lot of the BOZ constants (like z'00FF') for the hex integer 00FF. In f95 these are ONLY allowed in data statements. As of f2003 you can also use them in int, float, dble, cmplx statements. This is kind of restrictive though! Our current use was a gnu extension. I also remove the use of the exit intrinsic in the examples. It's not standard and to be honest "stop" is fine for our use and keeps things clean. I do not intend working on the f77 bindings. The C side could be cleaned up in the same way as the f95 bindings if anyone fancies it. Andrew |
From: Alan W. I. <ir...@be...> - 2011-10-19 17:39:36
|
Hi Arjen: Now that you have put in a notice in README.release about the future deprecation of our f77 bindings and examples, and Andrew has done such great work making our f95 bindings and examples much more compliant with the Fortran 95 standard, I think our next obvious Fortran step is to follow up by using more of the power of Fortran 95 in our f95 examples. For example, I understand that intrinsic functions like sin, cos, etc., can take array arguments and return the corresponding array results (just like the corresponding numpy Python capability that is used in examples/python/xw??.py) so using this Fortran 95 capability should eliminate many of the do loops in our examples. That is just one Fortran 95 capability we are currently not using in our f95 examples, but I am sure you can find some more since most of our f95 examples started life as a copy of our f77 examples. So could you please review some of our f95 examples and list how they could be simplified/modernized by using the full powers of Fortran 95? I would be very happy to learn more about Fortran 95 capability so once you have put together such a list and demonstrated what needs to be done for one our more complicated examples (say, example 16), I would be willing to help with some of the editing work required to propagate such simplification/modernization changes to all our f95 examples. 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 __________________________ |
From: Andrew R. <and...@us...> - 2011-10-19 17:49:27
|
On Fri, Oct 14, 2011 at 01:37:30AM -0700, Alan Irwin wrote: > On 2011-10-14 08:26+0100 Andrew Ross wrote: > > > I've committed the first tranche of fixes for compiler warnings. > > > > For reference I've been testing with > > CFLAGS="-O3 -std=c99 -pedantic -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wnested-externs -Wconversion -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings" > > CCFLAGS=-O3 -fvisibility=hidden -std=c++98 -pedantic -Wall -Wextra > > FFLAGS=-O3 -fvisibility=hidden -pedantic -Wall -Wextra > > > > When required I have (by hand) added -D_POSIX_C_SOURCE=1 to the flags for > > specific files (e.g. xwin.c) in order to compile. > > > > So far this is just the easy to fix issues (function prototypes, missing > > braces, missing const for char *, shadowed variables, unused functions.) > > This is quite intrusive, so please test well. > > Ordinary compile flags > > CXXFLAGS=-O3 -fvisibility=hidden > CFLAGS=-O3 -fvisibility=hidden > FFLAGS=-O3 > > now give the following warning: > > /home/software/plplot_svn/HEAD/plplot_cmake_qt/src/plargs.c: In > function ?ProcessOpt?: > /home/software/plplot_svn/HEAD/plplot_cmake_qt/src/plargs.c:1119: > warning: assignment discards qualifiers from pointer target type > > which wasn't there before. > > Other than that as of revision 11970 (my style changes on top of > your compiler warning fixes up to just before that revision), > > ctest -j4 > > shows no obvious issues. By the way, I just discovered that "parallel > test" option -j4 really does speed ctest execution on a machine with > two physical processors. > > > There will be more to come. > > Good work, Andrew! I have now completed the bulk of this work. Remaining are - the issue of unused parameters in function calls (see) below - some non-standard functions (see below) - some pointer aliasing rules which we use internally which break strict i C99 standards - a number of examples where we neglect the const argument for const char * , particularly for string literals (i.e. fixed strings given in quotes). - swig generated interfaces are very dirty, and much less easily fixed. - issues with external library headers (e.g. wxwidgets) which break the C99 / C++98 standards. The const issue is particularly problematic for Tcl / Tk where the Tcl / Tk API makes a lot of use of char * when it really means const char *. Casting does not make these warnings go away as casting cannot make a read-only string writeable. Non C99 function calls which we use strdup - SVr4, 4.3BSD, POSIX.1-2001 finite - SVID 4, BSD. Discouraged - replaced with isfinite. isfinite - C99, POSIX.1-2001 popen - POSIX.1-2001 pclose - POSIX1-2001 readlink - 4.2BSD, POSIX.1-2001 fdopen - POSIX.1-1990 mkstemp - 4.3BSD, POSIX.1-2001 vfork - 4.3BSD, POSIX.1-2001 but later removed. Discouraged - replaced with fork. fork - SVr4, 4.3BSD, POSIX.1-2001 All the additional functions we use are in the POSIX 2001 standard, or earlier so compiling with -std=c99 -D_POSIX_C_SOURCE=200112L added to the CFLAGS will work (i.e. C99 language standard with POSIX 2001 extensions). Some of these are not supported by some common compilers (e.g. isfinite) so will still need checks. The issue of unused function parameters is not entirely clear. The warnings are potentially useful for identifying e.g. errors in parameter names. Removing unused parameters is often not possible, either because it is an API change or because the function template requires the arguments (e.g. pltr or mapform functions which are passed as arguments to PLplot). Ideally unused parameters would be marked, both to make it clear to the programmer that they are unused and to silence the compiler warnings. There is no standard way of doing this. Possibilities include - Casting the parameter to void, which is a nop but will silence the warning. This doesn't catch any subsequent use of the parameter. This could be wrapped in a macro to make it explicit that the purpose is to mark the parameter as not used. - Adding a macro around the unused parameter name, e.g. void func( int UNUSED(x) ) The macro could do various things. GCC has a __attribute__((unused)) which can be applied to parameters to mark them as unused. One reference I came across suggested also mangling the parameter name to make sure it isn't accidentally used anywhere in the function. On non-gcc compilers there may be other ways of marking the parameter. C++ (but not C) allows you to comment out the parameter name. Worst case is that the macro does nothing other than alert the programmer to the fact the parameter is unused. One example I came across was #ifdef UNUSED #elif defined(__GNUC__) # define UNUSED(x) UNUSED_ ## x __attribute__((unused)) #elif defined(__LCLINT__) # define UNUSED(x) /*@unused@*/ x #else # define UNUSED(x) x #endif I have a slight preference for the UNUSED macro approach, but I'm open to suggestions. Either way we should adopt a consistent PLplot style for such things if we consider it important. Silencing the known safe warnings makes any real errors much more apparent. Andrew |
From: Andrew R. <and...@us...> - 2011-10-19 17:52:39
|
On Wed, Oct 19, 2011 at 10:39:28AM -0700, Alan Irwin wrote: > Hi Arjen: > > Now that you have put in a notice in README.release about the future > deprecation of our f77 bindings and examples, and Andrew has done such > great work making our f95 bindings and examples much more compliant > with the Fortran 95 standard, I think our next obvious Fortran step is > to follow up by using more of the power of Fortran 95 in our f95 > examples. > > For example, I understand that intrinsic functions like sin, cos, > etc., can take array arguments and return the corresponding array > results (just like the corresponding numpy Python capability that is > used in examples/python/xw??.py) so using this Fortran 95 capability > should eliminate many of the do loops in our examples. > > That is just one Fortran 95 capability we are currently not using in > our f95 examples, but I am sure you can find some more since most of > our f95 examples started life as a copy of our f77 examples. So could > you please review some of our f95 examples and list how they could be > simplified/modernized by using the full powers of Fortran 95? > > I would be very happy to learn more about Fortran 95 capability so > once you have put together such a list and demonstrated what needs to > be done for one our more complicated examples (say, example 16), I > would be willing to help with some of the editing work required to > propagate such simplification/modernization changes to all our f95 > examples. I have changed a few things which were not wrong, but were not the f95 way of doing it, e.g. variable definitions. There is a lot more that could be done. One thing I didn't add - if you want to compile the f95 bindings with -std=f95 at the moment, you also need to add -fall-intrinsics to work around the non-f95 intrinsics we currently use. This is a bit of a sledge hammer approach, but is useful to know for now while we consider which standard we want to follow. Andrew |