Hi Andrew: We need further followups from you when you can find the time.
More details below in context. On 2013-10-19 22:09-0700 Alan W. Irwin wrote: > On 2013-10-19 12:53-0700 Alan W. Irwin wrote: > >> Well, there are 74 such instances.... [in the make.out generated by > MSVC]. > > It turned out that -O0 -Wuninitialized picked up those 74 issues as > well (on Linux). So I fixed those (revision 12611). None of those > were false alarms, but they all concerned the fail: path, i.e., > whenever the python PLplot wrapper function was called with a bad > argument, so potentially could have created extra real issues for that case. > > I have since discovered that -O3 -Wuninitialized shows additional > issues in the bindings/python/plplotcmodulePYTHON_wrap.c file > generated in the build tree by swig. These are less obvious to fix, > but I plan to work on that first thing tomorrow (Sunday). All the > above was tested with 64-bit Linux with no run-time issues when > generating python results and no differences between those and the C > results (which is expected since that has been the case for a while). I fixed one of those concerning the legline argument of plstripc (revision 12613) but there are two other sets of uninitialized variables concerning the arguments of the c_plmeridians and c_plmap calls where there is a problematic style where certain error conditions can just drop through to the calls of the functions causing uninitialized arguments. Of course, this is not a problem for our tests because we don't make any errors in the calls to plmeridians or plmap. But this problematic style might cause a nasty surprise for users who do have some errors in the arguments to those python routine. @Andrew: I cannot figure out what causes the change to this problematic style generated by swig for how the floating point arguments are treated for those two functions, compared to the good style used for (say) the floating-point arguments of plenv. Since plmeridians and plmap are the only functions that use the mapform callback, I suspect the typemap for it is somehow screwing up the style for these functions, but that is as far as I can take this. Would you be willing to take a further look using the warning messages generated by gcc -O3 -Wuninitialized? (Note, I got these compiler warnings about the potential uninitialized arguments for c_plmeridans and c_plmap for both the 64-bit Linux platform and the 32-bit MinGW/MSYS/Wine platform when gcc -O3 -Wuninitialized was used.) > > I am holding off on testing anything on MinGW/MSYS/Wine until the > Linux -O3 -Wuninitialized result is free of warnings for > bindings/python/plplotcmodulePYTHON_wrap.c. Of course, I am not sure > that any of this work will solve the python-C comparison issues for > MinGW (and possibly gcc) on 32-bit systems, but I feel it is a good > idea to systematically get rid of all "obvious" uninitialized warnings > this way just in case one of them does affect that issue. > > I also fixed (I hope, since gcc does not warn about it) the following > warning in your make.out file: > > D:\plplot-svn\plplot\drivers\ps.c(599) : warning C4244: 'initializing' > : conversion from 'PLFLT' to 'int', possible loss of data > > What I did in that case was convert all the macros used for such > comparisons to floating point numbers. (revision 12611). The MinGW/MSYS results are better for me now. The remaining list is python Missing examples : Differing postscript output : 00 03 04 05 06 08 09 11 12 14a 15 16 17 18 20 21 22 23 25 26 27 29 33 Missing stdout : Differing stdout : 23 where 19 is now perfect and all of the ones with differences are usually 0.01 per cent. The exceptions are example 17 and 25 with large differences according to ndiff (but I cannot see anything visually) and example 20 with 1 per cent maximum differences (having to do with color settings) according to ndiff. (The previous run I had large differences for 17, 20, 22, and 25.) Every improvement to the Python interface I have made between the two runs can be classified as removing uninitialized variables from failure paths not executed by our standard examples. So I am pretty sure these improvements are because I am currently using gcc -O3 while the results before were derived with gcc with no optimization (-O0). That result (and the lack of any effect for MSVC) is still consistent with the uninitialized variable hypothesis since the two gcc optimizations and the different MSVC compiler will all execute code in very different orders with a different memory footprint. The result is the uninitialized variable would be moved around in the memory so it is affected by different bit patterns. @Andrew: I think Arjen and I have done as much as we can do here so I hope you are willing to follow this up with further investigation especially if you can confirm the 32-bit gcc troubles on Linux as well. 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 __________________________ ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
