Re: [Python-Dev] Compiler warnings
On Tue, Jan 31, 2006 at 08:16:21PM -0500, Tim Peters wrote: Is this version of gcc broken in some way relative to other gcc versions, or newer, or ... ? We certainly don't want to see warnings under gcc, since it's heavily used, but I'm not clear on why other versions of gcc aren't producing these warnings (or are they, and people have been ignoring that?). Well, I said 4.0.3, and that was wrong. It's actually a pre-release of 4.0.3 (in Debian's 'unstable' distribution.) However, 4.0.2 (the actual release) behaves the same way. The normal make process shows quite a lot of output on systems that use gcc, so I wouldn't be surprised if people did ignore it, for the most part. My main problem with fixing the warnings is that I don't see the difference between, for example, the 'ssize' variable and the 'nchannels' variable in linuxaudio's lad_obuffree/lad_bufsize/lad_obufcount. 'ssize' gets a warning, 'nchannels' doesn't, yet how they are treated is not particularly different. The ssize output parameter gets set inside a switch, is directly followed by a break, and the switch is directly followed by a set of the nchannels output parameter. The only way through the switch is through the set of ssize. I understand the compiler doesn't see it this way, but who knows for how long :) I guess we ignore this until we're closer to a 2.5alpha1 ;P -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
Thomas Wouters wrote: On Tue, Jan 31, 2006 at 08:16:21PM -0500, Tim Peters wrote: Is this version of gcc broken in some way relative to other gcc versions, or newer, or ... ? We certainly don't want to see warnings under gcc, since it's heavily used, but I'm not clear on why other versions of gcc aren't producing these warnings (or are they, and people have been ignoring that?). Well, I said 4.0.3, and that was wrong. It's actually a pre-release of 4.0.3 (in Debian's 'unstable' distribution.) However, 4.0.2 (the actual release) behaves the same way. The normal make process shows quite a lot of output on systems that use gcc, so I wouldn't be surprised if people did ignore it, for the most part. My main problem with fixing the warnings is that I don't see the difference between, for example, the 'ssize' variable and the 'nchannels' variable in linuxaudio's lad_obuffree/lad_bufsize/lad_obufcount. 'ssize' gets a warning, 'nchannels' doesn't, yet how they are treated is not particularly different. The ssize output parameter gets set inside a switch, is directly followed by a break, and the switch is directly followed by a set of the nchannels output parameter. The only way through the switch is through the set of ssize. I understand the compiler doesn't see it this way, but who knows for how long :) I guess we ignore this until we're closer to a 2.5alpha1 ;P I don't quite understand what's the big deal. The compiler issues a warning. We know better (and I agree, we *do* know better in most of these cases), but it's easy to add a = 0 to the declaration of the variable to shut up the compiler, hopefully with a comment saying as much. That's what I've been doing in my code that generated these warnings. It's clearly a bug in the compiler that it isn't smart enough to figure out that variable do actually only get used after they've been set. Hence, this is Somebody Else's Problem. -- Sjoerd Mullender signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
Thomas Wouters wrote: My main problem with fixing the warnings is that I don't see the difference between, for example, the 'ssize' variable and the 'nchannels' variable As was pointed out elsewhere, any variable that is passed by-reference to another function is ignored for the purposes of these warnings. The fact that the ioctl call with nchannels happens well after potential problem spots doesn't matter. It appears that GCC has eliminated it from the decision process for the purposes of these warnings already. The problem roots from the ambiguity of the returns. At compile-time, there is no way for GCC that the return value will be negative in the error case, and thus the return may cause us to go down an execution path that ssize (and nchannels) need to be initialized. This check seems to be very shallow, even if you provide a guarantee that the return value will be well-behaved, GCC has already given up on figuring this out. The rule of thumb here seems to be if you make a call to a function which provides the condition for the uninitialized variable is used, then the condition is decided to be ambiguous. So, either the GCC people have not noticed this problem, or (more likely) have decided that this is acceptable, but clearly it will cause spurious warnings. Hey, after all, they are just warnings. -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
On Wed, Feb 01, 2006 at 01:51:03PM +, Michael Hudson wrote: Scott Dial [EMAIL PROTECTED] writes: So, either the GCC people have not noticed this problem, or (more likely) have decided that this is acceptable, but clearly it will cause spurious warnings. Hey, after all, they are just warnings. Well, indeed, but no warnings is a useful policy -- it makes new warnings much easier to spot :) The warnings under discussion seem rather excessive to me. Yes, and more than that; fixing them 'properly' requires more than just initializing them. There is no sane default for some of those warnings, so a proper fix would have to check for a sane value after the function returns. That is, if we take the warning seriously. If we don't take it seriously, initializing the variable may surpress a warning in the future: one of the called functions could change, opening a code path that in fact doesn't initialize the output variable. But initializing to a sentinel value, checking the value before use and handling that case sanely isn't always easy, or efficient. Hence my suggestion to let this wait a bit (since they are, at this time, spurious errors). Fixing the warnings *now* won't fix any bugs, may mask future bugs, and may not be necessary if gcc 4.0.4 grows a better way to surpress these warnings. Or gcc 4.0 may grow more such warnings, in which case we may want to change the 'no warnings' policy or the flags to gcc, or add a 'known spurious warnings' checking thing to the buildbot. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
[Martin v. Löwis]
It inlines the function to make this determination.
Very cool! Is this a new(ish) behavior?
Now, it's not true that e can be uninitialized then, but there
the gcc logic fails:
That's fine -- there are any number of ways a compiler can reach a
wrong conclusion by making conservative assumptions, and so long as
it's actually staring at code I don't mind that at all. What I would
mind is griping about some_func(a) possibly not setting `a` in the
_absence_ of staring at `some_func`'s internals.
If you take the
if (vv == NULL || !PyLong_Check(vv)) {
PyErr_BadInternalCall();
return -1;
}
case in _PyLong_AsScaledDouble, *exponent won't be initialized.
Certainly, and I don't expect a compiler to realize that this branch
is impossible when _PyLong_AsScaledDouble is invoked from the call
sites where gcc is complaining.
Then, in PyLong_AsDouble, with
x = _PyLong_AsScaledDouble(vv, e);
if (x == -1.0 PyErr_Occurred())
return -1.0;
it looks like the return would not be taken if PyErr_Occurred returns
false. Of course, it won't, but that is difficult to analyse.
PyLong_AsDouble already did:
if (vv == NULL || !PyLong_Check(vv)) {
PyErr_BadInternalCall();
return -1;
}
before calling _PyLong_AsScaledDouble(), and the latter's `x` is the
former's `vv`. That is, the check you showed above from
_PyLong_AsScaledDouble() is exactly the same as the check
PyLong_AsDouble already made. To exploit that, gcc would have to
realize PyLong_Check() is a pure enough function, and I don't expect
gcc to be able to figure that out.
I don't know. Is this version of gcc broken in some way relative to
other gcc versions, or newer, or ... ? We certainly don't want to see
warnings under gcc, since it's heavily used, but I'm not clear on why
other versions of gcc aren't producing these warnings (or are they,
and people have been ignoring that?).
gcc 4 does inlining in far more cases now.
OK then. Thomas, for these _PyLong_AsScaledDouble()-caller cases, I
suggest doing whatever obvious thing manages to silence the warning.
For example, in PyLong_AsDouble:
int e = -1; /* silence gcc warning */
and then add:
assert(e = 0);
after the call.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
Thomas Wouters wrote: On Wed, Feb 01, 2006 at 01:51:03PM +, Michael Hudson wrote: Scott Dial [EMAIL PROTECTED] writes: So, either the GCC people have not noticed this problem, or (more likely) have decided that this is acceptable, but clearly it will cause spurious warnings. Hey, after all, they are just warnings. Well, indeed, but no warnings is a useful policy -- it makes new warnings much easier to spot :) The warnings under discussion seem rather excessive to me. Yes, and more than that; fixing them 'properly' requires more than just initializing them. There is no sane default for some of those warnings, so a proper fix would have to check for a sane value after the function returns. That is, if we take the warning seriously. If we don't take it seriously, initializing the variable may surpress a warning in the future: one of the called functions could change, opening a code path that in fact doesn't initialize the output variable. But initializing to a sentinel value, checking the value before use and handling that case sanely isn't always easy, or efficient. Hence my suggestion to let this wait a bit (since they are, at this time, spurious errors). Fixing the warnings *now* won't fix any bugs, may mask future bugs, and may not be necessary if gcc 4.0.4 grows a better way to surpress these warnings. Or gcc 4.0 may grow more such warnings, in which case we may want to change the 'no warnings' policy or the flags to gcc, or add a 'known spurious warnings' checking thing to the buildbot. Although it is no consolation, there are two types of unused variable warnings: the known-error (is used uninitialized in this function) and a probable-error (may be used uninitialized in this function). It may be reasonable to ignore the probable-error case. I think someone even mentioned that they really should be an info and not a warning. The points in the code clearly should have attention brought to them because there is a real possibility of error, but as you say, there is no way to rid yourself of this type of warning. Also, note that the phrasing is/may be is a change from 3.x to 4.x. The old warning was might always, and as I understand gcc the might of 3.x maps directly to the is of 4.x -- leaving may be an entirely new thing to 4.x. From gcc/tree-ssa.c: The second pass follows PHI nodes to find uses that are potentially uninitialized. In this case we can't necessarily prove that the use is really uninitialized. This pass is run after most optimizations, so that we thread as many jumps and possible, and delete as much dead code as possible, in order to reduce false positives. We also look again for plain uninitialized variables, since optimization may have changed conditionally uninitialized to unconditionally uninitialized. -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
[Thomas Wouters] Well, I said 4.0.3, and that was wrong. It's actually a pre-release of 4.0.3 (in Debian's 'unstable' distribution.) However, 4.0.2 (the actual release) behaves the same way. The normal make process shows quite a lot of output on systems that use gcc, so I wouldn't be surprised if people did ignore it, for the most part. Does it really? It's completely warning-free on Windows, and that's the intent, and it takes ongoing work to keep it that way. Over at, e.g., http://www.python.org/dev/buildbot/g5%20osx.3%20trunk/builds/46/step-compile/0 I only see one gcc warning, coming from Python/Python-ast.c. I suppose that isn't a complete build, though. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
Sjoerd Mullender wrote: I don't quite understand what's the big deal. Traditionally, people see two problems with these initializations: - the extra initialization may cause a performance loss. - the initialization might hide real bugs later on. For example, if an additional control flow branch is added which fails to initialize the variable, you don't get the warning anymore, not even from compilers which previously did a correct analysis. Whether this is a big deal, I don't know. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
Tim Peters wrote: It inlines the function to make this determination. Very cool! Is this a new(ish) behavior? In 3.4: http://gcc.gnu.org/gcc-3.4/changes.html # A new unit-at-a-time compilation scheme for C, Objective-C, C++ and # Java which is enabled via -funit-at-a-time (and implied by -O2). In # this scheme a whole file is parsed first and optimized later. The # following basic inter-procedural optimizations are implemented: # # - ... The actual might be uninitialized warning comes from the SSA branch, which was merged in 4.0, as somebody else pointed out. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
On Wed, Feb 01, 2006 at 11:29:16AM -0500, Tim Peters wrote: [Thomas Wouters] Well, I said 4.0.3, and that was wrong. It's actually a pre-release of 4.0.3 (in Debian's 'unstable' distribution.) However, 4.0.2 (the actual release) behaves the same way. The normal make process shows quite a lot of output on systems that use gcc, so I wouldn't be surprised if people did ignore it, for the most part. Does it really? It's completely warning-free on Windows, and that's the intent, and it takes ongoing work to keep it that way. Over at, e.g., No, it's mostly warning-free, it just outputs a lot of text. By default, the warnings don't stand out much. And if you have a decent computer, it scrolls by pretty fast, too. ;) -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
On Wed, Feb 01, 2006 at 10:15:15AM -0500, Tim Peters wrote: Thomas, for these _PyLong_AsScaledDouble()-caller cases, I suggest doing whatever obvious thing manages to silence the warning. For example, in PyLong_AsDouble: int e = -1; /* silence gcc warning */ and then add: assert(e = 0); after the call. Done, although it was nowhere near obvious to me that -1 would be a sane sentinel value ;) Not that I don't believe you, but it took some actual reading of _PyLong_AsScaledDouble to confirm it. Reading--imagine-that-ly y'rs, -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
Thomas Wouters [EMAIL PROTECTED] writes: On Wed, Feb 01, 2006 at 11:29:16AM -0500, Tim Peters wrote: [Thomas Wouters] Well, I said 4.0.3, and that was wrong. It's actually a pre-release of 4.0.3 (in Debian's 'unstable' distribution.) However, 4.0.2 (the actual release) behaves the same way. The normal make process shows quite a lot of output on systems that use gcc, so I wouldn't be surprised if people did ignore it, for the most part. Does it really? It's completely warning-free on Windows, and that's the intent, and it takes ongoing work to keep it that way. Over at, e.g., No, it's mostly warning-free, it just outputs a lot of text. By default, the warnings don't stand out much. And if you have a decent computer, it scrolls by pretty fast, too. ;) make -s is a wonderful thing :) Cheers, mwh -- In case you're not a computer person, I should probably point out that Real Soon Now is a technical term meaning sometime before the heat-death of the universe, maybe. -- Scott Fahlman [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
Thomas thanks.. useful string ... bob On 2/1/06, Michael Hudson [EMAIL PROTECTED] wrote: Thomas Wouters [EMAIL PROTECTED] writes: On Wed, Feb 01, 2006 at 11:29:16AM -0500, Tim Peters wrote: [Thomas Wouters] Well, I said 4.0.3, and that was wrong. It's actually a pre-release of 4.0.3 (in Debian's 'unstable' distribution.) However, 4.0.2 (the actual release) behaves the same way. The normal make process shows quite a lot of output on systems that use gcc, so I wouldn't be surprised if people did ignore it, for the most part. Does it really? It's completely warning-free on Windows, and that's the intent, and it takes ongoing work to keep it that way. Over at, e.g., No, it's mostly warning-free, it just outputs a lot of text. By default, the warnings don't stand out much. And if you have a decent computer, it scrolls by pretty fast, too. ;) make -s is a wonderful thing :) Cheers, mwh -- In case you're not a computer person, I should probably point out that Real Soon Now is a technical term meaning sometime before the heat-death of the universe, maybe. -- Scott Fahlman [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/evdo.hsdpa%40gmail.com -- Robert Q Kim, Wireless Internet Advisor http://evdo-coverage.com/cellular-repeater.html http://hsdpa-coverage.com http://evdo-coverage.com/pocket-pc-pda-ppc.html 2611 S. Pacific Coast Highway 101 Suite 102 Cardiff by the Sea, CA 92007 206 984 0880 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
Thomas Wouters wrote: I also noticed test_logging is spuriously failing, and not just on my machine (according to buildbot logs.) Is anyone (Vinay?) looking at that yet? I looked at it, and I couldn't figure it out. It appears that the last line of communication is somehow lost, but I could not find out why that might happen. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
On Tue, Jan 31, 2006 at 06:04:45PM +0100, Martin v. Löwis wrote: Thomas Wouters wrote: I also noticed test_logging is spuriously failing, and not just on my machine (according to buildbot logs.) Is anyone (Vinay?) looking at that yet? I looked at it, and I couldn't figure it out. It appears that the last line of communication is somehow lost, but I could not find out why that might happen. Not just the last line, see below. It never happens, as far as I can tell, when the test_logging test is run alone; it never once broke in several hundred solo tests. When I ran all combinations of a non-logging test followed by test_logging, it seems to break fairly randomly with almost all tests. Certainly not just tests that deal with signals, subprocesses, threads or sockets, also with tests like test_dircache, test_cookielib, test_coding, test_filecmp, and others. Just about the only correlation that makes sense is the duration of the first test. Not all of the other tests trigger test_logging's failure in any degree of reliability, although I get the feeling tests that take longer trigger the bug more often -- except that a test consisting of 'time.sleep(30)' never triggered it. All in all, it seems like a timing issue -- the timing is different because the previous test already imported some modules. The test_logging test uses threads, *ugh*. I tried adding a few Event-waits and time.sleep()'s at strategic places, but it doesn't seem to matter. Regardless of my pinpointing efforts, much more than just the last line is sometimes missing, though: $ ./python -E -tt Lib/test/regrtest.py -uall test_dircache test_logging test_dircache test_logging test test_logging produced unexpected output: ** *** line 515 of expected output missing: - DEB - WARNING: Message 16 (via logrecv.tcp.DEB) *** line 521 of expected output missing: - UNDEF - INFO: Message 22 (via logrecv.tcp.UNDEF) *** line 524 of expected output missing: - INF - INFO: Finish up, it's closing time. Messages should bear numbers 0 through 24. (via logrecv.tcp.INF) ** I've 'seen' at least all messages between 16 and 22 disappear, although not more than 3 or 4 in total. There's only ever messages missing, never out of order or garbled. I'm starting to think there might actually be a bug in the logging module ;P -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
Thomas Wouters wrote: All in all, it seems like a timing issue -- the timing is different because the previous test already imported some modules. The test_logging test uses threads, *ugh*. I tried adding a few Event-waits and time.sleep()'s at strategic places, but it doesn't seem to matter. Regardless of my pinpointing efforts, much more than just the last line is sometimes missing, though: Can you create a truss/strace dump of a failed run (I tried, but it always succeeded for me when run under strace). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
On Tue, Jan 31, 2006 at 09:04:39PM +0100, Martin v. Löwis wrote: Thomas Wouters wrote: All in all, it seems like a timing issue -- the timing is different because the previous test already imported some modules. The test_logging test uses threads, *ugh*. I tried adding a few Event-waits and time.sleep()'s at strategic places, but it doesn't seem to matter. Regardless of my pinpointing efforts, much more than just the last line is sometimes missing, though: Can you create a truss/strace dump of a failed run (I tried, but it always succeeded for me when run under strace). Nope, they always succeed when run under strace. I haven't been able to capture the supposedly-TCP traffic either, not even when binding and connecting to my actual IP address. I wonder if glibc is doing trickery because it sees both endpoints of the socket are in the same process. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
[Thomas Wouters] I noticed a few compiler warnings, when I compile Python on my amd64 with gcc 4.0.3: Objects/longobject.c: In function 'PyLong_AsDouble': Objects/longobject.c:655: warning: 'e' may be used uninitialized in this function Well, that's pretty bizarre. There's _obviously_ no way to get to a reference to `e` without going through x = _PyLong_AsScaledDouble(vv, e); first. That isn't a useful warning. Objects/longobject.c: In function 'long_true_divide': Objects/longobject.c:2263: warning: 'aexp' may be used uninitialized in this function Objects/longobject.c:2263: warning: 'bexp' may be used uninitialized in this function Same thing, really, complaining about vrbls whose values are always set by _PyLong_AsScaledDouble(). Modules/linuxaudiodev.c: In function 'lad_obuffree': Modules/linuxaudiodev.c:392: warning: 'ssize' may be used uninitialized in this function Modules/linuxaudiodev.c: In function 'lad_bufsize': Modules/linuxaudiodev.c:348: warning: 'ssize' may be used uninitialized in this function Modules/linuxaudiodev.c: In function 'lad_obufcount': Modules/linuxaudiodev.c:369: warning: 'ssize' may be used uninitialized in this function Those are Linux bugs ;-) ... Should these warnings be fixed? I don't know. Is this version of gcc broken in some way relative to other gcc versions, or newer, or ... ? We certainly don't want to see warnings under gcc, since it's heavily used, but I'm not clear on why other versions of gcc aren't producing these warnings (or are they, and people have been ignoring that?). I know Tim has always argued to fix them, in the past (and I agree,) and it doesn't look like doing so, by initializing the variables, wouldn't be too big a performance hit. We shouldn't see any warnings under a healthy gcc. I also noticed test_logging is spuriously failing, and not just on my machine (according to buildbot logs.) Is anyone (Vinay?) looking at that yet? FWIW, I've never seen this fail on Windows. The difference is probably that sockets on Windows work wink. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
On 1/31/06, Tim Peters [EMAIL PROTECTED] wrote: [Thomas Wouters] Objects/longobject.c:655: warning: 'e' may be used uninitialized in this function Well, that's pretty bizarre. There's _obviously_ no way to get to a reference to `e` without going through x = _PyLong_AsScaledDouble(vv, e); first. That isn't a useful warning. But how can the compiler know that it is an output-only argument? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
Tim Peters wrote:
I noticed a few compiler warnings, when I compile Python on my amd64 with
gcc 4.0.3:
Objects/longobject.c: In function 'PyLong_AsDouble':
Objects/longobject.c:655: warning: 'e' may be used uninitialized in this
function
Well, that's pretty bizarre. There's _obviously_ no way to get to a
reference to `e` without going through
x = _PyLong_AsScaledDouble(vv, e);
first. That isn't a useful warning.
It inlines the function to make this determination. Now, it's not true
that e can be uninitialized then, but there the gcc logic fails:
If you take the
if (vv == NULL || !PyLong_Check(vv)) {
PyErr_BadInternalCall();
return -1;
}
case in _PyLong_AsScaledDouble, *exponent won't be initialized. Then,
in PyLong_AsDouble, with
x = _PyLong_AsScaledDouble(vv, e);
if (x == -1.0 PyErr_Occurred())
return -1.0;
it looks like the return would not be taken if PyErr_Occurred returns
false. Of course, it won't, but that is difficult to analyse.
I don't know. Is this version of gcc broken in some way relative to
other gcc versions, or newer, or ... ? We certainly don't want to see
warnings under gcc, since it's heavily used, but I'm not clear on why
other versions of gcc aren't producing these warnings (or are they,
and people have been ignoring that?).
gcc 4 does inlining in far more cases now.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
Guido van Rossum wrote: Well, that's pretty bizarre. There's _obviously_ no way to get to a reference to `e` without going through x = _PyLong_AsScaledDouble(vv, e); first. That isn't a useful warning. But how can the compiler know that it is an output-only argument? If a variable's address is passed to a function, gcc normally assumes that the function will modify the variable, so you normally don't see might be used uninitialized warnings. However, gcc now also inlines the functions called if possible, to find out how the pointer is used inside the function. Changing the order of the functions in the file won't help anymore, either. If you want to suppress inlining, you must put __attribute__((noinline)) before the function. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings for 64-bit portability problems
On 1/6/06, von Löwis Martin [EMAIL PROTECTED] wrote: I just found that the intel compiler (icc 9.0) also supports compiler warnings for portability problems. Cool. Thanks for the info. It would be nice if Intel would provide Python developers with a permanent icc license for Python. Can anyone help with that? 4. don't try the Intel install.sh, it won't work (atleast, it didn't work for me) I don't follow directions very well (I'm also a doubter), so I had to try it myself. :-) It worked for me on gentoo amd64 non-root install. I needed to set LD_LIBRARY_PATH to ~/intel/cce/9.0/lib, but otherwise it was pretty painless. This worked: CC=icc ./configure --without-cxx But I think this should work too: CC=icc CXX=icc ./configure I've fixed a bunch of problems on HEAD. I think I will move to ssize branch since that will be a much bigger help. I have some outstanding modifications, but here are the results of make: http://python.org/neal/icc-warnings.txt Summary (type, warning count, description): warning.#170:2 pointer points outside of underlying object (obmalloc.c PT(0)) warning.#188: 14 enumerated type mixed with another type warning.#810: 1478 conversion from long to int may lose significant bits warning.#1418: 137 external definition with no prior declaration warning.#1419: 53 external declaration in primary source file warning.#1684: 285 conversion from pointer to same-sized integral type (potential portability problem) -- all due to offsetof() remark.#111: 121 statement is unreachable remark.#177:1 func marshal_write_mod was declared but never referenced remark.#181:9 arg is incompatible w/corresponding format string conversion remark.#279: 862 controlling expression is constant remark.#593: 17 variable set, but not used remark.#869: 1317 parameter not used remark.#981: 130 operands are evaluated in unspecified order remark.#1469: 10 cc clobber ignored (wtf? use of htons() causes this msg) remark.#1572: 111 floating-point equality/inequality comparisons are unreliable remark.#1599: 30 declaration hides parameter Note there are a lot of warning even when we mask off the higher bits (e.g., x = y 0xff still generats a warning if x is a char). n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings for 64-bit portability problems
On 1/7/06, Neal Norwitz [EMAIL PROTECTED] wrote: Cool. Thanks for the info. It would be nice if Intel would provide Python developers with a permanent icc license for Python. Can anyone help with that? I'll try. A dutch friend from long ago (CWI) is now working for Intel's compiler group and has tried to interest me in providing feedback about their compiler (and also their alternative to valgrind). I'll contact him. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
