From: Arjen M. <Arj...@de...> - 2013-10-18 07:08:05
|
Hi Alan, (changed the subject to better reflect the content) The problems I had before with building the Python bindings had to do with MinGW and the location of the Numpy package. The current problems are however of a very different nature. I removed the #define NPY_NO_DEPRECATED_API ... line from plplotcmodule.i, even though this has been in there for a long time, and that helped a bit: the complaints about PyArray_FLOAT are gone. The other error messages still exist, though. It concerns lines like: tmpGrid2.xg[i] = (PLFLT *) ( PyArray_DATA( pltr_xg ) + i * size ); PyArray_DATA is a helper function of type "void *". Now that I look at it in the morning with a fresh cup of coffee, I think the problem is clear: pointer arithmetic on a "void *" pointer. My hunch is that this line should read: tmpGrid2.xg[i] = ((PLFLT *) PyArray_DATA( pltr_xg ) + i * size ); Yes, a quick test shows that then the messages disappear. This requires some further investigation. The PyArray_FLOAT symbol occurs only in the function do_mapform_callback(), in an #ifdef block, controlled by PL_HAVE_PTHREAD. As I am trying to build it on bare Windows, that macro is not defined and so I get into the #else branch. My question: Is the #ifdef really required? One branch uses PyArray_SimpleNewFromData() and the other PyArray_FromDimsAndData(). Neither strikes me as very dependent on Pthread capabilities, but that is only judging from the name and the calls themselves. I have not looked at the documentation. 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: Alan W. I. <ir...@be...> - 2013-10-18 08:03:23
|
On 2013-10-18 07:07-0000 Arjen Markus wrote: > [...]As I am trying to build it on bare Windows, that macro is not defined and so I get into the #else > branch. [...] Sorry, Arjen. I missed before that you were doing a build with bare Windows. I assume in the rest of this that means you having been using Microsoft's MSVC compiler for the issues you have recently been reporting? If so, my advice would be to suspend that work, and first confirm python on MinGW/MSYS works for you (like it should because of my Python success with that combination). And that would immediately give the result I am looking for which is does 32-bit python for MinGW/MSYS always give iffy numerical accuracy for Windows regardless of whether it is the Wine version or Microsoft version of that? Of course, after that MinGW/MSYS python success, you could go back to investigating the MSVC case further. But the point is that MinGW success for you would remove all doubt that your Python/NumPy installation was suitable for PLplot builds and provides a much better comparison for my Python results on Wine. > I removed the #define NPY_NO_DEPRECATED_API ... line from plplotcmodule.i, even though this has been in there for a long time, and that helped a bit: the complaints about PyArray_FLOAT are gone. You will probably want to restore #define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION later once you figure everything out for the MSVC case. See http://docs.scipy.org/doc/numpy-dev/reference/c-api.deprecations.html for why we will want that #define in place. Since this #define causes no issues for me on MinGW/MSYS (and shouldn't for you as well when you try MinGW/MSYS) I expect in your current MSVC case you are actually compiling slightly different code (due to conditional compilation) and thus running into some old deprecated ways of using numpy that have not been exercised by any of our MinGW/MSYS tests. 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...> - 2013-10-18 16:30:46
|
On 2013-10-18 01:03-0700 Alan W. Irwin wrote: > On 2013-10-18 07:07-0000 Arjen Markus wrote: >> I removed the #define NPY_NO_DEPRECATED_API ... line from > plplotcmodule.i, even though this has been in there for a long time, > and that helped a bit: the complaints about PyArray_FLOAT are gone. > > You will probably want to restore > > #define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION > > later once you figure everything out for the MSVC case. See > http://docs.scipy.org/doc/numpy-dev/reference/c-api.deprecations.html > for why we will want that #define in place. I have looked a bit more at this. That #define was put in by Andrew in revision 12340 in May this year as part of his large numeric removal and accompanying numpy fixup change. So it is not that old a change. >From his commit message it helped insure the code was clean (no compiler warnings) when compiled with numpy version 1.7, but, of course, that would only be a check of the part of our Python/numpy interface that is used in the Linux case, and from your experiences there appear to be other bits left for the Windows case that are not yet clean for numpy 1.7. For my previous tests of Python/numpy on my Debian wheezy platform, numpy is version 1.6.1, and for the MinGW/MSYS/Wine platform I chose to use numpy-1.5 so I have effectively bypassed all numpy API checks on both Linux and MinGW/MSYS/Wine. But when I move to numpy-1.7 for my python/numpy tests on MinGW/MSYS wine (hopefully later today) I anticipate I will run into the same warnings you encountered about code not being numpy-1.7 clean. With luck I should be able to fix all of those and as a result we should be clean against numpy-1.7 API in the Windows case. 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...> - 2013-10-19 03:58:44
|
On 2013-10-18 09:30-0700 Alan W. Irwin wrote: > On 2013-10-18 01:03-0700 Alan W. Irwin wrote: > >> On 2013-10-18 07:07-0000 Arjen Markus wrote: >>> I removed the #define NPY_NO_DEPRECATED_API ... line from >> plplotcmodule.i, even though this has been in there for a long time, >> and that helped a bit: the complaints about PyArray_FLOAT are gone. >> >> You will probably want to restore >> >> #define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION >> >> later once you figure everything out for the MSVC case. See >> http://docs.scipy.org/doc/numpy-dev/reference/c-api.deprecations.html >> for why we will want that #define in place. > > I have looked a bit more at this. That #define was put in by Andrew in > revision 12340 in May this year as part of his large numeric removal > and accompanying numpy fixup change. So it is not that old a change. >> From his commit message it helped insure the code was clean (no > compiler warnings) when compiled with numpy version 1.7, but, of > course, that would only be a check of the part of our Python/numpy > interface that is used in the Linux case, and from your experiences > there appear to be other bits left for the Windows case that are not > yet clean for numpy 1.7. For my previous tests of Python/numpy on my > Debian wheezy platform, numpy is version 1.6.1, and for the > MinGW/MSYS/Wine platform I chose to use numpy-1.5 so I have > effectively bypassed all numpy API checks on both Linux and > MinGW/MSYS/Wine. But when I move to numpy-1.7 for my python/numpy > tests on MinGW/MSYS wine (hopefully later today) I anticipate I will > run into the same warnings you encountered about code not being > numpy-1.7 clean. With luck I should be able to fix all of those and > as a result we should be clean against numpy-1.7 API in the Windows case. I did install python-2.7.5 and numpy-1.7.1, and immediately encountered the PyArray_FLOAT build errors Arjen encountered. I created a proper fix for those as of revision 12606. That allowed me to do a full test of MinGW/MSYS/Wine. The Python diff summary was the same as I got before: python Missing examples : Differing postscript output : 00 03 04 05 06 08 09 11 12 14 14a 15 16 17 18 19 20 21 22 23 25 26 27 29 33 Missing stdout : Differing stdout : 23 However, when I looked in detail at those results before and now, they mostly consist of small rounding errors. The exceptions in the previous test were the major differences for 17, 19, 20, 22, and 25, but for this test example 19 has improved to just a few minor differences. That substantial improvement in example 19 was the result of an actual precision bug fix for the mapform case that occurred as part of revision 12606. But I am still completely stumped as to why 32-bit python still has the major differences for the four remaining "bad" examples, and minor differences for many of the rest of the examples when all other languages I have tested on Wine produce perfectly clean results. So the next step in trying to figure out the cause of these problems should be to do some additional platform checks for 32-bit Python. Arjen is moving ahead with those for both the MinGW/MSYS and MSVC Microsoft Windows cases, and I am hoping Andrew will be able to check the 32-bit Python case on Linux. 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...> - 2013-10-19 14:13:28
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > > python > Missing examples : > Differing postscript output : 00 03 04 05 06 08 09 11 12 14 14a 15 16 17 18 19 20 > 21 22 23 25 26 27 29 33 > Missing stdout : > Differing stdout : 23 > Example 14 also shows minor differences due to rounding, but in the Python case I have to select the device twice, whereas the C example asks for it only once. I ran this example manually. Just a minor difference, but it did strike me as odd. 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: Arjen M. <Arj...@de...> - 2013-10-19 14:09:09
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > I did install python-2.7.5 and numpy-1.7.1, and immediately encountered the > PyArray_FLOAT build errors Arjen encountered. I created a proper fix for those as of > revision 12606. That allowed me to do a full test of MinGW/MSYS/Wine. The > Python diff summary was the same as I got before: > > python > Missing examples : > Differing postscript output : 00 03 04 05 06 08 09 11 12 14 14a 15 16 17 18 19 20 > 21 22 23 25 26 27 29 33 > Missing stdout : > Differing stdout : 23 > > However, when I looked in detail at those results before and now, they mostly consist > of small rounding errors. The exceptions in the previous test were the major > differences for 17, 19, 20, 22, and 25, but for this test example 19 has improved to > just a few minor differences. That substantial improvement in example 19 was the > result of an actual precision bug fix for the mapform case that occurred as part of > revision 12606. > > But I am still completely stumped as to why 32-bit python still has the major > differences for the four remaining "bad" examples, and minor differences for many of > the rest of the examples when all other languages I have tested on Wine produce > perfectly clean results. > > So the next step in trying to figure out the cause of these problems should be to do > some additional platform checks for 32-bit Python. > Arjen is moving ahead with those for both the MinGW/MSYS and MSVC Microsoft > Windows cases, and I am hoping Andrew will be able to check the 32-bit Python > case on Linux. > I have used the MinGW 32-bits platform on Windows to do the same test. I see minor differences in the following examples: 00 03 04 05 06 08 09 11 12 15 16 17 18 20 21 22 23 25 26 27 29 and 33. So that list is almost the same as yours, except for example 19 - that is completely clean. I did not run example 14 yet and there is no example x14a. The examples that show significant differences are: 17 and 25 - the PostScript files show extra lines or completely different lines in these two cases. I also noted that many differences occur with lines like: 1349 220 M (Python) -- 1350 220 M (C) ... 1800 M (Python) -- ... 1799 M (C) I have not checked what PLplot command is responsible for them, but they occur in many examples, so I guess they have to do with the frames. I will continue with example 14 and then move on to MSVC ... 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: Arjen M. <Arj...@de...> - 2013-10-19 15:20:17
|
Hi Alan, Andrew, here are the results for Python on the Windows platform using MSVC/C++ 2010 (32 bits): - I had to build with the CMake build type set to Release (otherwise a package bug kicks in: Python 2.7 inserts a dependency on python27_d.lib which is the debug library that is missing from the installation) - I had to correct a few casts in plplotcmdule.i - MSVC/C++ is pickier than gcc, It seems. - I had to turn off the Java bindings, as there is something in there MSVC/C++ does not like either. I have not looked into that yet. - Most of the Python examples produce the same results as the corresponding C examples. - The ones that do not simply crash at some point. These are: 08, 09, 11, 15, 16, 20, 21 and 22. I have not looked into the possible cause of this. It may be a single function that is causing this. It may be a set of functions. Anyway, this means that the mystery is only larger: The Python installation was _exactly_ the same under Windows/MSVC as under Windows/MinGW. Regards, Arjen > -----Original Message----- > From: Arjen Markus [mailto:Arj...@de...] > Sent: Saturday, October 19, 2013 4:09 PM > To: Alan W. Irwi > Cc: PLplot development list; Andrew Ross > Subject: Re: [Plplot-devel] Problem builiding the Python bindings on Windows using > MS VC/C++ > > Hi Alan, > > > -----Original Message----- > > From: Alan W. Irwin [mailto:ir...@be...] > > I did install python-2.7.5 and numpy-1.7.1, and immediately > > encountered the PyArray_FLOAT build errors Arjen encountered. I > > created a proper fix for those as of revision 12606. That allowed me > > to do a full test of MinGW/MSYS/Wine. The Python diff summary was the same as > I got before: > > > > python > > Missing examples : > > Differing postscript output : 00 03 04 05 06 08 09 11 12 14 14a 15 > > 16 17 18 19 20 > > 21 22 23 25 26 27 29 33 > > Missing stdout : > > Differing stdout : 23 > > > > However, when I looked in detail at those results before and now, they > > mostly consist of small rounding errors. The exceptions in the > > previous test were the major differences for 17, 19, 20, 22, and 25, > > but for this test example 19 has improved to just a few minor > > differences. That substantial improvement in example 19 was the result > > of an actual precision bug fix for the mapform case that occurred as part of revision > 12606. > > > > But I am still completely stumped as to why 32-bit python still has > > the major differences for the four remaining "bad" examples, and minor > > differences for many of the rest of the examples when all other > > languages I have tested on Wine produce perfectly clean results. > > > > So the next step in trying to figure out the cause of these problems > > should be to do some additional platform checks for 32-bit Python. > > Arjen is moving ahead with those for both the MinGW/MSYS and MSVC > > Microsoft Windows cases, and I am hoping Andrew will be able to check > > the 32-bit Python case on Linux. > > > > I have used the MinGW 32-bits platform on Windows to do the same test. I see minor > differences in the following examples: > 00 03 04 05 06 08 09 11 12 15 16 17 18 20 21 22 23 25 26 27 29 and 33. > > So that list is almost the same as yours, except for example 19 - that is completely > clean. > > I did not run example 14 yet and there is no example x14a. > > The examples that show significant differences are: 17 and 25 - the PostScript files > show extra lines or completely different lines in these two cases. > > I also noted that many differences occur with lines like: > > 1349 220 M (Python) -- 1350 220 M (C) > ... 1800 M (Python) -- ... 1799 M (C) > > I have not checked what PLplot command is responsible for them, but they occur in > many examples, so I guess they have to do with the frames. > > I will continue with example 14 and then move on to MSVC ... > > 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. > > ------------------------------------------------------------------------------ > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > 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: Arjen M. <Arj...@de...> - 2013-10-19 17:08:55
|
Hi Alan, Andrew, > -----Original Message----- > From: Arjen Markus [mailto:Arj...@de...] > > - The ones that do not simply crash at some point. These are: 08, 09, 11, 15, 16, 20, > 21 and 22. > I have not looked into the possible cause of this. It may be a single function that is > causing this. > It may be a set of functions. > That was my mistake - I should have looked better at the statements that MSVC/C++ did not accept. When I corrected the casts all was well. No rounding errors and all examples working fine. I will check in the changes. 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: Alan W. I. <ir...@be...> - 2013-10-19 16:50:05
|
Hi Arjen: Thanks very much for running the Python-C comparisons for both MinGW/MSYS (and later) MSVC on 32-bit Windows. More below in context. On 2013-10-19 14:08-0000 Arjen Markus wrote: >> From: Alan W. Irwin [mailto:ir...@be...] >> So the next step in trying to figure out the cause of these problems should be to do >> some additional platform checks for 32-bit Python. >> Arjen is moving ahead with those for both the MinGW/MSYS and MSVC Microsoft >> Windows cases, and I am hoping Andrew will be able to check the 32-bit Python >> case on Linux. >> > > I have used the MinGW 32-bits platform on Windows to do the same test. I see minor differences > in the following examples: > 00 03 04 05 06 08 09 11 12 15 16 17 18 20 21 22 23 25 26 27 29 and 33. > > So that list is almost the same as yours, except for example 19 - that is completely clean. Although Wine has a pretty good track record for being a good Windows test platform, I was concerned that I might have stumbled over some issue that was due to some Wine bug. But from your MinGW/MSYS results (and later MSVC results) on Microsoft Windows, this problem first turned up with Wine turns out to be a widespread issue on 32-bit Windows. And the "jury is still out" on whether this is also an issue with 32-bit Linux. > > I did not run example 14 yet and there is no example x14a. > > The examples that show significant differences are: 17 and 25 - the PostScript files show extra > lines or completely different lines in these two cases. > > I also noted that many differences occur with lines like: > > 1349 220 M (Python) -- 1350 220 M (C) > ... 1800 M (Python) -- ... 1799 M (C) > > I have not checked what PLplot command is responsible for them, but they occur in many examples, > so I guess they have to do with the frames. Those are PostScript commands generated by the ps device driver. That driver issues alias commands like /M {moveto} def in the top of the file so the first "M" command you see above simply mean move the pen to coordinate 1349 220. So differences like above mean that C and Python (on all 32-bit Windows platforms we have tested between us) have slightly different views of the overall coordinate transformations that yield the above positions. But the puzzle is that all those transformations are done in our C library and the "psc" C device in both cases depending only on the input coordinates entered, for example, in the plenv call for x00. And I also proved with the gdb debugging tool that those input coordinates were identical in that particular case. So in the 32-bit case we have proved that our core C library, libplplotd and/or the psc device, gives different answers with the _same_ input data in the C and Python cases for at least one example, and that might be the cause of all the above issues. My working hypothesis to explain this unusual result is some memory management issue (e.g., an uninitialized variable) in our core C library and/or our ps device that generates some unpredictability in the results. A further hypothesis is that Python has a very large memory footprint so it leaves non-zero bit patterns behind scattered over a wide memory space, and one of those non-zero bit patterns is being interpreted differently by the uninitialized variable than when any other language is being used to run the examples. In later e-mail concerning the MSVC case you stated the following results: <quote> - Most of the Python examples produce the same results as the corresponding C examples. - The ones that do not simply crash at some point. These are: 08, 09, 11, 15, 16, 20, 21 and 22. I have not looked into the possible cause of this. It may be a single function that is causing this. It may be a set of functions. Anyway, this means that the mystery is only larger: The Python installation was _exactly_ the same under Windows/MSVC as under Windows/MinGW. </quote> I think these results are also consistent with the working hypothesis that there is a lurking memory management issue in our core C library and/or the ps device driver code for the 32-bit case. So Arjen, if you have access to a static or dynamic memory debugging tool for Windows (see a partial list of such tools for all operating systems at http://en.wikipedia.org/wiki/Memory_debugging), I suggest you run it on x00c (our simplest 2D plot example written in C) to see if it spots some memory management issue (uninitialized variable or whatever) in libplplotd, our core C library. And, of course, if MinGW or MSVC is giving any warning messages at all concerning the compilation of our core C library, we should try to address those warnings. The only memory debugging tool I have access to is valgrind (a dynamic analysis tool) which can only be run on Linux (and Mac OS X). That gives totally clean results for x00c for the 64-bit Linux case where Python and C results are identical. For the record, here are those results: software@raven> valgrind examples/c/x00c -dev psc -o test.ps ==19591== Memcheck, a memory error detector ==19591== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==19591== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==19591== Command: examples/c/x00c -dev psc -o test.ps ==19591== ==19591== ==19591== HEAP SUMMARY: ==19591== in use at exit: 0 bytes in 0 blocks ==19591== total heap usage: 457 allocs, 457 frees, 132,045 bytes allocated ==19591== ==19591== All heap blocks were freed -- no leaks are possible ==19591== ==19591== For counts of detected and suppressed errors, rerun with: -v ==19591== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) However, now that our combined results show there is a widespread 32-bit issue for the Windows case (triggered by Python, but I think that is the result of the large Python memory footprint and nothing to do with bad Python code or bad code interfacing Python with our core C library), we need followup with extensive testing for the 32-bit Linux case. Therefore, I strongly encourage Andrew (or someone else here with access to 32-bit Linux) to compare Python and C results and if those are different do valgrind runs to help us get to the bottom of these issues. 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...> - 2013-10-19 17:17:20
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Saturday, October 19, 2013 6:50 PM > To: Arjen Markus > Cc: PLplot development list; Andrew Ross > Subject: RE: [Plplot-devel] Problem builiding the Python bindings on Windows using > MS VC/C++ > > Hi Arjen: > > Thanks very much for running the Python-C comparisons for both MinGW/MSYS > (and later) MSVC on 32-bit Windows. More below in context. ... > > > My working hypothesis to explain this unusual result is some memory management > issue (e.g., an uninitialized variable) in our core C library and/or our ps device that > generates some unpredictability in the results. A further hypothesis is that Python > has a very large memory footprint so it leaves non-zero bit patterns behind scattered > over a wide memory space, and one of those non-zero bit patterns is being > interpreted differently by the uninitialized variable than when any other language is > being used to run the examples. > > In later e-mail concerning the MSVC case you stated the following > results: > > <quote> > - Most of the Python examples produce the same results as the corresponding C > examples. > > - The ones that do not simply crash at some point. These are: 08, 09, 11, 15, 16, 20, > 21 and 22. > I have not looked into the possible cause of this. It may be a single function that is > causing this. > It may be a set of functions. > > Anyway, this means that the mystery is only larger: The Python installation was > _exactly_ the same under Windows/MSVC as under Windows/MinGW. > </quote> > > I think these results are also consistent with the working hypothesis that there is a > lurking memory management issue in our core C library and/or the ps device driver > code for the 32-bit case. > > So Arjen, if you have access to a static or dynamic memory debugging tool for > Windows (see a partial list of such tools for all operating systems at > http://en.wikipedia.org/wiki/Memory_debugging), I suggest you run it on x00c (our > simplest 2D plot example written in C) to see if it spots some memory management > issue (uninitialized variable or > whatever) in libplplotd, our core C library. And, of course, if MinGW or MSVC is > giving any warning messages at all concerning the compilation of our core C library, > we should try to address those warnings. > Well, the fact that I now get perfectly matching results for Python and C under Windows/MSVC, means that the likelihood of an uninitialised variable/memory location is strongly reduced. The crashes were simply my mistake. I did notice a number of warnings while building the libraries and examples and it is worthwhile to examine those. (There is also the Java issue for this platform.) Debugging is going to be tough: I can not build with the Debug build type because of the Python problem I mentioned. This means I would have to try and debug an executable that is not built for debugging. Hm, the MinGW platform does allow the Debug build, maybe that is a possibility. 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: Arjen M. <Arj...@de...> - 2013-10-19 18:46:09
|
Hi Alan, > -----Original Message----- > From: Arjen Markus [mailto:Arj...@de...] ... > (There is also the Java issue for this platform.) Well, that is solved too: just a few small corrections to the wrapper code and some juggling with the PATH variable that were required on my machine and I can now confirm that the Java bindings build fine with MSVC/C++ and that the Java examples produce the same results as the C examples. There are some strange issues with CMake though. I will write those down in a separate mail. 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: Arjen M. <Arj...@de...> - 2013-10-19 17:22:23
Attachments:
make.out
|
The compiler warnings do not seem to be of much interest - I have attached the full output of nmake, but I do not see anything that could help us with this rounding problem. Regards, Arjen > -----Original Message----- > From: Arjen Markus [mailto:Arj...@de...] ... > > I did notice a number of warnings while building the libraries and examples and it is > worthwhile to examine those. (There is also the Java issue for this platform.) > > Debugging is going to be tough: I can not build with the Debug build type because of > the Python problem I mentioned. This means I would have to try and debug an > executable that is not built for debugging. Hm, the MinGW platform does allow the > Debug build, maybe that is a possibility. > 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: Alan W. I. <ir...@be...> - 2013-10-19 18:43:11
|
On 2013-10-19 17:22-0000 Arjen Markus wrote: > The compiler warnings do not seem to be of much interest - I have attached the full output of nmake, > but I do not see anything that could help us with this rounding problem. On the contrary, I think these results might be more interesting than implied by your summary. For example, your attachment shows there are lots of possibly uninitialized variables noted by the MSVC compiler in the swig-generated C code interfacing Python with PLplot. I will take a look at those to see whether they are real uninitialized variables or just false alarms. More later. 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...> - 2013-10-19 18:49:03
|
HI Alan, from a first glance, I think they are false alarms - they show up in clean-up code. But that is only a preliminary conclusion from just a glance. The conversions from PLFLT to int are innocent as they are not related to anything that could produce the rouding errors in the PostScript files. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Saturday, October 19, 2013 8:43 PM > To: Arjen Markus > Cc: PLplot development list; Andrew Ross > Subject: RE: [Plplot-devel] Problem builiding the Python bindings on Windows using > MS VC/C++ > > On 2013-10-19 17:22-0000 Arjen Markus wrote: > > > The compiler warnings do not seem to be of much interest - I have > > attached the full output of nmake, but I do not see anything that could help us with > this rounding problem. > > On the contrary, I think these results might be more interesting than implied by your > summary. For example, your attachment shows there are lots of possibly > uninitialized variables noted by the MSVC compiler in the swig-generated C code > interfacing Python with PLplot. I will take a look at those to see whether they are real > uninitialized variables or just false alarms. > > More later. > > 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: Alan W. I. <ir...@be...> - 2013-10-19 19:53:23
|
On 2013-10-19 18:48-0000 Arjen Markus wrote: > HI Alan, > > from a first glance, I think they are false alarms - they show up in clean-up code. But > that is only a preliminary conclusion from just a glance. Hi Arjen: Well, there are 74 such instances. I agree the first one for tmp8 seems to be associated with cleanup code for failure conditions associated with the fail: label. But that is worth fixing since if a Python user enters the wrong argument type, for example, we don't want the whole of python to segfault because of that uninitialized variable. And once that uninitialized variable result is fixed in bindings/python/plplotcmodule.i, it will automatically fix a significant fraction of the remaining 74 such instances in the code generated by swig. Which may leave some uninitialized variable in that code that has even bigger impact than the uninitialized variables in cleanup code for failure conditions that we have already identified. Or as you say this code cleanup might not have any impact on the different Python-C results we get for the MinGW compiler (and which Andrew might still be able to confirm for the closely related gcc compiler as well on 32-bit Linux.) But the code cleanup is worthwhile in its own right so let me have a first crack at that. I plan to use the -Wuninitialized' gcc option which is supposed to detect possible uninitialized variables. But if MSVC does a better job of detecting such conditions, I might need you to do another evaluation with it after I have fixed everything that is mentioned by the gcc -Wuninitialized' option for the Python interface. More later.... 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...> - 2013-10-20 05:10:05
|
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 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). More tomorrow (Sunday). 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...> - 2013-10-21 04:50:28
|
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 __________________________ |
From: Andrew R. <and...@us...> - 2013-10-21 21:12:00
|
Alan, Firstly, the 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. Compiling plplotcmodule with -O3 -Wuninitialized I get the same warnings for plmap and plmeridian that Alan reports. From the swig generated code it is clear why this is the case. The arg variable initialization code is surrounded by some if statements. What is not at all clear is why swig generates different code for this case compared to the other functions. I will continue to delve further. (Swig version 2.0.10). Andrew On Sunday 20 Oct 2013 21:50:21 Alan W. Irwin wrote: > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Andrew R. <and...@us...> - 2013-10-21 21:35:08
|
I now understand why the code is different. The typemap for mapform_func mapform has a default clause which controls what happens if the argument is omitted. It seems that once swig has encountered an optional argument all subsequent arguments are also counted as optional so are wrapped with an if statement. The subsquent arguments do not have a default value though, hence the uninitialized variable warning. If the function is correctly called then the variables _will_ be defined, but if not then it would cause an error. To see this just comment out the lines // you can omit the mapform func %typemap( default ) mapform_func mapform { python_mapform = 0; $1 = NULL; } in plplotcmodule.i and all will compile without warnings. It seems that plmap and plmeridian are the only functions where one of these callback functions is used early on in the option list before other more standard options. I'm not sure quite what the best way of fixing this is. It seems like a swig "feature". One could probably work round by including a default statement for every typemap, but we don't particularly want to do that. Ideas Alan? Andrew On Monday 21 Oct 2013 22:11:50 Andrew Ross wrote: > Alan, > > Firstly, the 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. > > Compiling plplotcmodule with -O3 -Wuninitialized I get the same warnings for > plmap and plmeridian that Alan reports. From the swig generated code it is > clear why this is the case. The arg variable initialization code is > surrounded by some if statements. What is not at all clear is why swig > generates different code for this case compared to the other functions. I > will continue to delve further. (Swig version 2.0.10). > > Andrew > > On Sunday 20 Oct 2013 21:50:21 Alan W. Irwin wrote: > > 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.clktr > > k > > _______________________________________________ > > Plplot-devel mailing list > > Plp...@li... > > https://lists.sourceforge.net/lists/listinfo/plplot-devel > > ---------------------------------------------------------------------------- > -- 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2013-10-22 00:30:27
|
On 2013-10-21 22:34+0100 Andrew Ross wrote: > > I now understand why the code is different. The typemap for mapform_func > mapform has a default clause which controls what happens if the argument is > omitted. It seems that once swig has encountered an optional argument all > subsequent arguments are also counted as optional so are wrapped with an if > statement. The subsquent arguments do not have a default value though, hence > the uninitialized variable warning. If the function is correctly called then > the variables _will_ be defined, but if not then it would cause an error. > > To see this just comment out the lines > > // you can omit the mapform func > %typemap( default ) mapform_func mapform { > python_mapform = 0; > $1 = NULL; > } > > in plplotcmodule.i and all will compile without warnings. It seems that plmap > and plmeridian are the only functions where one of these callback functions is > used early on in the option list before other more standard options. > > I'm not sure quite what the best way of fixing this is. It seems like a swig > "feature". One could probably work round by including a default statement for > every typemap, but we don't particularly want to do that. Ideas Alan? I had no further ideas at all before you asked that, but I got a bit more inspiration from reading the swig-2.0 documentation. That documentation of default typemaps says the following: <quote> 10.5.5 "default" typemap The "default" typemap is used to turn an argument into a default argument. For example: %typemap(default) int flags { $1 = DEFAULT_FLAGS; } ... int foo(int x, int y, int flags); The primary use of this typemap is to either change the wrapping of default arguments or specify a default argument in a language where they aren't supported (like C). Target languages that do not support optional arguments, such as Java and C#, effectively ignore the value specified by this typemap as all arguments must be given. Once a default typemap has been applied to an argument, all arguments that follow must have default values. See the Default/optional arguments section for further information on default argument wrapping. </quote> That last paragraph explains why we are getting peculiar behaviour for all other arguments of plmap and plmeridians. Those additional arguments are all PLFLT for plmeridians and char* and PLFLT for plmap. So I think you might be able to fix that by changing those additional arguments to unique names and defining ordinary and default typemaps for those unique names that works just like the nondefault PLFLT we use everywhere else (i.e., Python throws an error if the user omits the argument). I also followed the default/optional arguments link in the above documentation which might yield another possibility of dealing with this issue. For example, what happens if you change bindings/swig-support/plplotcapi.i so plmeridians is treated like this: plmeridians( mapform_func mapform, PLFLT dlong, PLFLT dlat, PLFLT minlong, PLFLT maxlong, PLFLT minlat, PLFLT maxlat ); #ifdef SWIG_PYTHON plmeridians( mapform_func mapform=NULL, PLFLT dlong, PLFLT dlat, PLFLT minlong, PLFLT maxlong, PLFLT minlat, PLFLT maxlat ); #endif and the default typemap is removed for mapform_func mapform? That documentation implies NULL will be propagated to the C call (which is what we want), but I am not sure how the swig-generated python interface will distinguish between when a user specifies a mapform argument or not and whether the above logic for bindings/swig-support/plplotcapi.i should be changed so that plmeridians only has one definition for python (or any other language). Anyhow, I hope I have given you some more food for thought. 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...> - 2013-10-22 02:07:42
|
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 __________________________ |
From: Alan W. I. <ir...@be...> - 2013-10-22 04:37:04
|
On 2013-10-21 19:07-0700 Alan W. Irwin wrote: > 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. I can only reproduce these valgrind issues for example 16 if a certain amount (-O2 or -O3) of optimization is turned on. Here are the valgrind warnings for the -g -O2 case (which were identical to these same 10 warnings for the -g -O3 case, but -g -O1 or -g -O0 were valgrind perfect): software@raven> valgrind examples/c/x16c -dev psc -o test.ps ==17878== Memcheck, a memory error detector ==17878== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==17878== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==17878== Command: examples/c/x16c -dev psc -o test.ps ==17878== ==17878== Invalid read of size 4 ==17878== at 0x4E76FF7: draw_box (pllegend.c:936) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x402407: main (x16c.c:271) ==17878== Address 0x6b93904 is 4 bytes inside a block of size 6 alloc'd ==17878== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==17878== by 0x4E76EE5: draw_box (pllegend.c:1069) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x402407: main (x16c.c:271) ==17878== ==17878== Invalid read of size 4 ==17878== at 0x4E76FF7: draw_box (pllegend.c:936) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x402A7E: main (x16c.c:323) ==17878== Address 0x6d0ed24 is 4 bytes inside a block of size 6 alloc'd ==17878== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==17878== by 0x4E76EE5: draw_box (pllegend.c:1069) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x402A7E: main (x16c.c:323) ==17878== ==17878== Invalid read of size 4 ==17878== at 0x4E76FF7: draw_box (pllegend.c:936) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x40292C: main (x16c.c:375) ==17878== Address 0x7094734 is 4 bytes inside a block of size 6 alloc'd ==17878== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==17878== by 0x4E76EE5: draw_box (pllegend.c:1069) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x40292C: main (x16c.c:375) ==17878== ==17878== Invalid read of size 4 ==17878== at 0x4E76FF7: draw_box (pllegend.c:936) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x4027DA: main (x16c.c:426) ==17878== Address 0x72a31c4 is 4 bytes inside a block of size 6 alloc'd ==17878== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==17878== by 0x4E76EE5: draw_box (pllegend.c:1069) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x4027DA: main (x16c.c:426) ==17878== ==17878== Invalid read of size 4 ==17878== at 0x4E76FF7: draw_box (pllegend.c:936) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x402559: main (x16c.c:528) ==17878== Address 0x7564bf4 is 4 bytes inside a block of size 6 alloc'd ==17878== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==17878== by 0x4E76EE5: draw_box (pllegend.c:1069) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x402559: main (x16c.c:528) ==17878== ==17878== ==17878== HEAP SUMMARY: ==17878== in use at exit: 0 bytes in 0 blocks ==17878== total heap usage: 44,458 allocs, 44,458 frees, 6,533,752 bytes allocated ==17878== ==17878== All heap blocks were freed -- no leaks are possible ==17878== ==17878== For counts of detected and suppressed errors, rerun with: -v ==17878== ERROR SUMMARY: 10 errors from 5 contexts (suppressed: 4 from 4) So this probably has something to do with optimization screwing up the recursive function, remove_characters, but the -O2 optimization removes so much from what is accessible to gdb, that I cannot figure out what might be the issue. Would you be willing to take a look at how that function is defined to see if you spot anything problematic there? Sorry I could not solve it. Tomorrow (Tuesday) I plan to move on to working on the uninitialized variables in the code in the src subdirectory that are revealed by -O3 -Wuninitialized to help work toward the overall goal of getting rid of all these warnings throughout our source tree. 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...> - 2013-10-26 02:28:31
|
On 2013-10-21 21:36-0700 Alan W. Irwin wrote: > I can only reproduce these valgrind issues for example 16 if a certain > amount (-O2 or -O3) of optimization is turned on. Here are the > valgrind warnings for the -g -O2 case (which were identical to these > same 10 warnings for the -g -O3 case, but -g -O1 or -g -O0 were > valgrind perfect): > > software@raven> valgrind examples/c/x16c -dev psc -o test.ps > ==17878== Memcheck, a memory error detector > ==17878== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et > al. > ==17878== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright > info > ==17878== Command: examples/c/x16c -dev psc -o test.ps > ==17878== > ==17878== Invalid read of size 4 > ==17878== at 0x4E76FF7: draw_box (pllegend.c:936) > ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) > ==17878== by 0x402407: main (x16c.c:271) > ==17878== Address 0x6b93904 is 4 bytes inside a block of size 6 alloc'd > ==17878== at 0x4C28BED: malloc (vg_replace_malloc.c:263) > ==17878== by 0x4E76EE5: draw_box (pllegend.c:1069) > ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) > ==17878== by 0x402407: main (x16c.c:271) > ==17878== > ==17878== Invalid read of size 4 > ==17878== at 0x4E76FF7: draw_box (pllegend.c:936) > ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) > ==17878== by 0x402A7E: main (x16c.c:323) > ==17878== Address 0x6d0ed24 is 4 bytes inside a block of size 6 alloc'd > ==17878== at 0x4C28BED: malloc (vg_replace_malloc.c:263) > ==17878== by 0x4E76EE5: draw_box (pllegend.c:1069) > ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) > ==17878== by 0x402A7E: main (x16c.c:323) > ==17878== > ==17878== Invalid read of size 4 > ==17878== at 0x4E76FF7: draw_box (pllegend.c:936) > ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) > ==17878== by 0x40292C: main (x16c.c:375) > ==17878== Address 0x7094734 is 4 bytes inside a block of size 6 alloc'd > ==17878== at 0x4C28BED: malloc (vg_replace_malloc.c:263) > ==17878== by 0x4E76EE5: draw_box (pllegend.c:1069) > ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) > ==17878== by 0x40292C: main (x16c.c:375) > ==17878== > ==17878== Invalid read of size 4 > ==17878== at 0x4E76FF7: draw_box (pllegend.c:936) > ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) > ==17878== by 0x4027DA: main (x16c.c:426) > ==17878== Address 0x72a31c4 is 4 bytes inside a block of size 6 alloc'd > ==17878== at 0x4C28BED: malloc (vg_replace_malloc.c:263) > ==17878== by 0x4E76EE5: draw_box (pllegend.c:1069) > ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) > ==17878== by 0x4027DA: main (x16c.c:426) > ==17878== > ==17878== Invalid read of size 4 > ==17878== at 0x4E76FF7: draw_box (pllegend.c:936) > ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) > ==17878== by 0x402559: main (x16c.c:528) > ==17878== Address 0x7564bf4 is 4 bytes inside a block of size 6 alloc'd > ==17878== at 0x4C28BED: malloc (vg_replace_malloc.c:263) > ==17878== by 0x4E76EE5: draw_box (pllegend.c:1069) > ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) > ==17878== by 0x402559: main (x16c.c:528) > ==17878== > ==17878== > ==17878== HEAP SUMMARY: > ==17878== in use at exit: 0 bytes in 0 blocks > ==17878== total heap usage: 44,458 allocs, 44,458 frees, 6,533,752 > bytes allocated > ==17878== > ==17878== All heap blocks were freed -- no leaks are possible > ==17878== > ==17878== For counts of detected and suppressed errors, rerun with: -v > ==17878== ERROR SUMMARY: 10 errors from 5 contexts (suppressed: 4 from > 4) > > So this probably has something to do with optimization screwing up the > recursive function, remove_characters, but the -O2 optimization > removes so much from what is accessible to gdb, that I cannot figure > out what might be the issue. Would you be willing to take a look at > how that function is defined to see if you spot anything problematic > there? Sorry I could not solve it. Hi Andrew: I have just discovered there is a real and rather weird symptom that can be observed on my platform as a result ofthis memory management issue with plcolorbar when optimization is -O2 or higher. For the -O1 optimization case, valgrind for example 33 is clean, and the interactive targets test_tcl_standard_examples and test_tk_standard_examples produce the correct superscript rendering for the exponent labels that appear by design for all the plcolorbar numerical axis labelling. For the -O3 optimization case, valgrind produces many error messages like above for example 33, and the interactive targets test_tcl_standard_examples and test_tk_standard_examples produce incorrect superscript rendering (the #u and #d are printed out on the same line as the rest of the exponent rather than treated as superscript and un-superscript escapes. For the same test_tcl_standard_examples and test_tk_standard_examples, example 1 (upper right subplot) exponent label rendering is fine regardless of optimization, and that example is valgrind clean also regardless of optimization. I have not seen the -O3 superscript rendering symptoms that occur for the numerical exponents of the axis for plcolobar except in the two specific cases noted above. I doubt anyone else on different platforms will see those specific issues, and other plcolorbar issues may pop up or not. This is the nature of the beast; memory management issues yield different results (and sometimes even good results) depending on circumstances. Anyhow, assuming you can figure out a way to solve the memory management issue with plcolorbar for -O2 and higher that are being revealed by valgrind, the above weird symptoms should go away. 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...> - 2013-10-24 19:12:22
|
On 2013-10-21 21:36-0700 Alan W. Irwin wrote: > Tomorrow (Tuesday) I plan to move on to working on the uninitialized > variables in the code in the src subdirectory that are revealed by -O3 > -Wuninitialized to help work toward the overall goal of getting rid of > all these warnings throughout our source tree. Hi Andrew: After some other PLplot distractions were finished off I got this done (revision 12625). During the process I actually found instances where -O3 -Wuninitialized gave a false alarm, but generally those are uncommon. Therefore, it is worthwhile searching out all instances of such warnings and fixing them if they are valid (the usual case) or doing some unnecessary initialization to quiet them (the uncommon case of a false alarm). I hope you will continue this process dealing with the -O3 -Wuninitialized warnings for our swig-generated code, and I plan to do the same for the rest of our code. 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...> - 2013-10-24 20:24:50
|
On 2013-10-24 12:12-0700 Alan W. Irwin wrote: > I hope you will continue this process dealing with the -O3 > -Wuninitialized warnings for our swig-generated code, and I plan to do > the same for the rest of our code. Hi Andrew: I just discovered for the test_noninteractive and install targets we are now clean for the -O3 -Wuninitialized case except for swig-generated code. So I believe my part of this "search and destroy" mission for dealing with uninitialized variables is now done, and I wish you the best trying to figure out what to do for the swig-generated cases. I now plan to shift my focus to some build_projects issues for the Tcl and Tk build that I have been trying to straighten out. 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 __________________________ |