On 2013-10-21 22:11+0100 Andrew Ross wrote: > > Alan, > > [... T]he rounding issues are not an intrinsic 32-bit issue. With a 32-bit > version of Debian unstable (running under pbuilder) I get completely clean > results for make test_diff_psc, with the exception of stdout for the python > example 23. This is with python 2.7.5.
Hi Andrew: I have just implemented a VALGRIND_ALL_TESTS option (revision 12616). (For others here, this option is OFF by default and is also OFF if there is no valgrind installed. Valgrind is normally not installed on Windows platforms since valgrind does not work for that case.) Will you try VALGRIND_ALL_TESTS on your 32-bit system? (Use the -DVALGRIND_ALL_TESTS=ON cmake option and run the test_c_psc target as described in the commit message.) When I tried that on my 64-bit Linux system I discovered plcolorbar memory management issues which I am planning to look at this evening. So with luck I should be able to achieve valgrind perfect results for all our examples in the 64-bit case. If tomorrow (Tuesday) your 32-bit system also yields perfect valgrind results, then that goes a long way toward proving we have good memory management for our C library and there are no relevant bugs in the Linux version of gcc for both 32 and 64 bits. Of course, then our screwed up results _where Python is known to have the same plplot arguments as in the equivalent C example_ would also imply the possibility of a bug in the MinGW form of gcc that screws up the memory management for our core C library. (I have presented that possibility in general terms without reference to the number of bits since we don't yet know what might be revealed by a 64-bit test for the MinGW case.) Meanwhile, I have yet to see any false positives from gcc-4.7.2 for -O3 -Wuninitalized. So I hope you keep plugging away on those generated by our swig interface (not only for Python, but also for Java, Lua, and Octave), and I will try to address the rest of the uninitialized warnings for code in the src directory and also the bad valgrind results for plcolorbar that I ran into above. It is a good goal to clean up all these memory management and uninitialized variable issues in any case (even if it turns out none of the fixups have anything to do with the problems encountered when the MinGW compiler is used). 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=60135991&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
