On Wednesday 30 Oct 2013 13:30:59 Alan W. Irwin wrote: > 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, That sounds like a sensible compromise to maintain standards compliance while keeping the code clear. Andrew ------------------------------------------------------------------------------ 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
