To James, Arjen, and Andrew:
I completed the recent thread entitled "Font setting parameters in
Fortran90" on plplot-general by revision revision 12640, where I had
tested that change with
FFLAGS=-O1 -Wuninitialized
and using gfortran and the test_f95_psc target (which compiles and
executes all our fortran examples using -dev psc).
However, it turns out that interpreting BOZ as an integer other
than in extremely specific cases is a gfortran extension.
For example, suppose you have the simple test code
integer :: i=z'4'
end
This compiles without issues for gfortran with no options (the default
case with extensions from the standards), but if you try the -std=f95,
-std=f2003, or -std=f2008 gfortran
options there is a build error:
integer :: i=z'4'
1
Error: Extension: BOZ literal at (1) outside a DATA statement and
outside INT/REAL/DBLE/CMPLX
And looking further at gfortran documentation "outside
INT/REAL/DBLE/CMPLX" refers to outside of those explicit
function calls so the "INT" does not refer to the above integer
declaration.
I have also looked at Intel Fortran compiler documentation I
downloaded years ago, and that compiler (at least in that era)
accepted a BOZ literal in the above statement but that feature was
also considered to be a Fortran 95 extension.
So I think we have a case here where the standards are far behind what
is implemented as extensions by various compilers. (Why would the
standards want to restrict the use of BOZ constants to exclude
something obvious like above?) But the nasty result for us if the
present commit was allowed to stand in its present form is we can no
longer use the gfortran -std= option to check for standards
compliance. That is too big a sacrifice in my opinion. On the other
hand, I do not want to go back to using the data form just for BOZ
constants since that has some irritating consequences for our users.
So to work around what I believe is an issue in the Fortran standards,
I have (revision 12641) replaced all BOZ constants by the equivalent
integers in bindings/f95/plplot_parameters.h.
Note I have used some explicit calculations here, e.g., z'400' ==>
4*16*16, in the sed script to continue to emphasize the typical
"single-bit-set" nature of these constants and more importantly to be
sure there are no mistakes in such conversions. Also note these
calculations of initializers are done at compile time rather than run
time and are allowed by Fortran 95 and higher standards.
I have checked the above commit using FFLAGS='-std=f95 -O1
-fall-intrinsics -Wuninitialized' and the test_diff_psc target, and
all seems to be well with no build warnings, run-time errors, or any
differences between the calculated f95 and C results.
So I am happy with how we are currently treating global numerical
constants for our f95 bindings and 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
__________________________
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
