Re: [Plplot-devel] Problem builiding the Python bindings on Windows using MS VC/C++

[Alan W. I. <ir...@be...>]

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
__________________________