New submission from Jean Brouwers:
Python 3.0a1 on Linux and MacOS X 10.4.10 exits differently than Python
2.4 and 2.5.
With previous Python binaries the destructor** function of any pre-
loaded shared library is called prior to exit. With Python 3.0a1 it is
not, neither when exiting Python
Jean Brouwers added the comment:
Here is one thought, maybe 3.0a calls _exit() while 2.x uses exit() to
terminate. With _exit() any functions installed with atexit() or
on_exit() are *not* called.
That would explain the difference but only if destructor functions are
installed with atexit
Jean Brouwers added the comment:
Sorry, premature submit. I will try using atexit() and report what
happens there.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Jean Brouwers added the comment:
Using atexit() to install the destructor function does not help. The
function in not called when 3.0a1 exits, but with 2.5.1 it is. Same
behavior on Linux and MacOS X.
Btw, that would mean that any C extension which uses atexit() directly
may be affected by
Jean Brouwers added the comment:
Yes, I will make a small library. But first, here is another piece of
evidence.
As I mentioned, using std atexit does not work on 3.0a1. But
surprisingly, the destructor function is not called either when
installed with Py_AtExit on 3.0a1. On 2.5.1 it is
Jean Brouwers added the comment:
Here is the same file with an #if to use to Py_AtExit or destructor case.
Please us this one instead of the earlier one.
Added file: http://bugs.python.org/file8622/dlibtest.c
__
Tracker <[EMAIL PROTECTED]>
Jean Brouwers added the comment:
Attached is a simple test case which demonstrates the problem on Linux
and MacOS X. It is not an xxmodule example, though and hope this is OK.
See the comments for build steps and example output with 3 different
Python builds on both platforms.
If you need
Jean Brouwers added the comment:
My fault, sorry. The command line to run should be
env LD_PRELOAD=./dlibtest.so ...
i.e. with '=' sign and no spaces. And the library file may have to be
an absolute path.
__
Tracker <[EMAIL PROT
Jean Brouwers added the comment:
One more thing. Stepping with the debugger thru Py_Finalize looks exactly
the same for 2.5.1 and 3.0a1 in the last part of that function.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Jean Brouwers added the comment:
The Py_AtExit function is in Python/pythonrun.c. The calls to all
installed C functions are made in call_ll_exitfuncs, also in
pythonrun.c. The call to call_ll_exitfuncs is at the very end of
Py_Finalize also in pythonrun.c.
I am just getting down there
Jean Brouwers added the comment:
I put a bunch of printf's in the Py_Finalize function of 2.5.1 and
3.0a1.
All those show up when 2.5.1 exists including the call to
call_ll_exitfuncs.
But in 3.0a1 only a few show up and the last one is just before the call
to PyImport_Cleanup near lin
Jean Brouwers added the comment:
This is quite bizarre and difficult to reproduce. With gdb, 3.0a1 does
get to the very end of Py_Finalize, but without gdb it doesn't.
Also, the call to static function call_all_exitfuncs is inlined, its
while loop is shown inside Py_Finalize on MacOS X
Jean Brouwers added the comment:
OK, I try that.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1329>
__
___
Python-bugs-list mailing list
Unsubs
Jean Brouwers added the comment:
The 3.0a1 build --with-pydebug behaves the same as before (on Linux). The
problem does occur without gdb but not with gdb.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Jean Brouwers added the comment:
It looks like the problem may indeed just be that I/O is being shut down
somewhere inside PyImport_Cleanup. I am modifying the test case to
demonstrate that and will submit that version as soon as it runs.
__
Tracker <[EM
Jean Brouwers added the comment:
Attached is an updated dlibtest.c file. It prints a message in the con-
/destructor functions and if that fails it calls _exit(9).
Compile and run it as before and check the exit status. If the latter
is 9 or 011, a printf error occurred indicating e.g. that
Jean Brouwers added the comment:
Yes, that is the expected behavior in this case.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1329>
__
___
Python-bugs-list
Jean Brouwers added the comment:
One final comment as confirmation. If the messages are written to a file,
other than stdout and stderr, they do appear in unpatched 3.0a1 and 3.0a1
behaves as expected. The root cause of the problem was the closed stdout
Jean Brouwers added the comment:
It is quite common to pre-load libraries into existing binaries e.g. for
profiling Typically, those write to stdout or stderr only if the option
for an output file is not used. That is how I happened to run into the
issue the other day.
For a while, the
Jean Brouwers added the comment:
One more argument. Without a fix, 3.0 would not even print a C debug
message from a destructor function nor from any function installed with
atexit or Py_AtExit. The dlibtest shows that for 2 of these 3.
__
Tracker <[EM
Jean Brouwers added the comment:
I could not try Neal's patch since it does not seem to apply to the
3.0a1 source I have. But the Modules/_fileio.c patch works just fine on
my Linux and MacOS X. Here is the Linux result:
$ env LD_PRELOAD=./dlibtest4.so ~/Python-3dbg/python
***
Jean Brouwers added the comment:
Perhaps, the proper behavior is the following.
After calling all functions/methods installed at the Python level with
atexit.register and all C functions installed with Py_AtExit, the
objects sys.stdin, sys.stdout and sys.stderr are destroyed.
However, the C
New submission from Jean Brouwers:
Building 3.0a1 on Solaris 10 using SUN's C/C++ compilers fails due to
one compilation error.
The problem is the name of the last argument 'restrict' of function
analyze_cells on line 473 in file Python/symtable.c. Changing that name
to some
New submission from Jean Brouwers:
The 3.0a1 Solaris build (see issue #1356) fails at the end of make test
with the following error:
test_zlib
278 tests OK.
5 tests failed:
test_cookielib test_email test_fileio test_pipes test_uuid
39 tests skipped:
test_aepack test_applesingle
Jean Brouwers added the comment:
Close it for now. Once I have the missing packages installed I will try
again.
My main concern was not the actual test failures, but the make test ***
Error 1 ... itself.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
There may be another reason to use a single summation function. The
summation functions does need (a copy of) the is_error() function from
the math module.
The cmath module has a similar function called math_error() which
sl
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10306/unnamed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2819>
__
_
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Two tests failed with Python 2.6a3 on MacOS X Intel.
Test 11 failed: 9007199254740992.0 vs 9007199254740991.0 expected for
[9007199254740992.0, -0.5, -5.5511151231257827e-17].
Test 12 failed: inf vs 1.7976931348623157e+308 expect
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
I intend to submit a C version of msum4 shortly.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2819>
__
_
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10364/mathmodule4.c.2.6a3.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Attached is the patch for the the mathmodule.c file of Python 2.6a3
containing the C version of the msum() function from Marks's msum4.py
Python implementation.
Please review the C code, in particular the setting of _do_su
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10365/mathmodule4.c.2.6a3.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10366/test_math_sum4.py
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10366/test_math_sum4.py
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10365/mathmodule4.c.2.6a3.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Attached are updated patches for both the mathmodule.c and cmathmodule.c
files for Python 2.6a3 and for the test_math_sum4.py script. Please
ignore the ones posted earlier.
Added file: http://bugs.python.org/file10371/mathmodule4.c
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10372/cmathmodule4.c.2.6a3.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10373/test_math_sum4.py
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
The tests of the test_math_sum4.py script all pass with the latest math-
and cmathmodule.c files for 4 different builds of Python 2.6a3:
- GNU gcc 4.0.1 on MacOS X 10.4.11 (Intel Core Duo), 32-bit
- GNU gcc 4.1.2 on RHEL 3 update 7 (O
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Here is another patch for the mathmodule.c and cmathmodule.c files updated
with the suggested and other modifications. Note, if FLT_RADIX is not 2,
the sum functions still exist but will raise a NotImplementedError.
An update of th
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10380/cmathmodule5.c.2.6a3.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10381/test_math_sum5.py
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Attached is revision 11 of the mathmodule.c patch for Python 2.6a3.
This one includes Raymond's full precision summation, Mark's rounding
partials addition and correct non-finites and error handling.
However, intermedia
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10406/test_math_sum11.py
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Here is rev 12 of the mathmodule.c patch. It is the same as rev 11 but
with additional code removed as requested:
- no FLT_RADIX 2 check
- no errno illustration in _do_sum_add2()
- no _do_sum() callback function argument
- no option
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10408/test_math_sum12.py
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Here is another, cleaner revision 19 of the same mathmodule.c patch and
the corresponding test_math_sum19.py script.
/Jean Brouwers
Added file: http://bugs.python.org/file10410/mathmodule19.c.2.6a
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10411/test_math_sum19.py
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Three questions on the sizeof.patch:
1) In the first line of function dict_sizeof()
+ res = sizeof(PyDictObject) + sizeof(mp->ma_table);
is the sizeof(mp->ma_table) counted twice?
2) Since functions list_sizeof and
New submission from Jean Brouwers <[EMAIL PROTECTED]>:
The test_multiprocessing hangs with both Python 2.6b1 and 3.0b1 on MacOS X
10.4.11 (Intel) but only when using make test.
However, the test runs and passes in both builds if run separately, e.g.
with ./python Li
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Sorry, this issue has already been raised in #3088. Please ignore.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Jean Brouwers <[EMAIL PROTECTED]>:
The multiprocessing module fails to build on Solaris 10 when using the
Sun C compiler. The failure is due to one missing symbol
SEM_VALUE_MAX.
Defining that symbol (e.g. as _POSIX_SEM_VALUE_MAX) builds the
_multiprocessing modu
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
One more comment on SEM_VALUE_MAX for Solaris. _POSIX_SEM_VALUE_MAX is
defined in on Solaris and that header file must be included.
Better might be to use _SEM_VALUE_MAX which is defined in and
that header files needs to be inclu
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
If the struct changes are made, add also 2 formats for C types ssize_t and
size_t, perhaps 'z' resp. 'Z'. In particular since on platforms
sizeof(size_t) != sizeof(long).
New submission from Jean Brouwers <[EMAIL PROTECTED]>:
Attached is a (simplistic) patch for the struct module to support C types
ssize_t and size_t with format characters 'z' resp. 'Z'.
The patch updates Python 2.6b1 files Modules/_struct.c and
Doc/library/struct.rs
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Please ignore the first patch. Use the rev2 patch which includes an
update for test file Lib/test/test_struct.py as well.
Added file: http://bugs.python.org/file10690/struct_size_t.rev2.patch
___
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10687/struct_size_t.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Jean Brouwers <[EMAIL PROTECTED]>:
There are 2 math test failures with 32-bit Python 2.6b1 and 3.0b1 on
Solaris 10 both built with Sun's C compiler. The failures do *not*
occur for the 64-bit builds. The same compiler options are used for all
these bui
New submission from Jean Brouwers <[EMAIL PROTECTED]>:
There is on cmath test failure with 64-bit Python 2.6b1 and 3.0b1 on
Solaris 10. The failure does not occur in the 32-bit builds.
All builds are compiled with Sun's C compiler using the same options
(except -xtarget=native
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Attached is a patch attempting to provide support for %f with precision in
PyString_FromFormat* based on file Objects/stringobject.c of Python 2.6b1.
Note, only %f is support but %lf is not and silently ignored.
--
keywords:
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10696/stringobject_format_f.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10697/stringobject_format_f.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Jean Brouwers <[EMAIL PROTECTED]>:
Test test_macos is reported as an "unexpected skip" on linux2 by Python
2.6b1 make test.
35 tests skipped:
...
test_macos test_macostools ...
...
2 skips unexpected on linux2:
test_tcl test_macos
$ uname -a
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Here is that in from 32- and 64-bit Python 2.6b1:
> ./python (32-bit)
Python 2.6b1 (r26b1:64398, Jun 20 2008, 09:20:49) [C] on sunos5
Type "help", "copyright", "credits" or "license" for mor
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Attached is another patch for file Objects/stringobject.c(relative to
Python 2.6b1) which supports the double %f and long double %LF formats.
However, %Lf is included only if symbol LDBL_DIG is defined in header
file on the unde
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10702/stringobject_format_Lf.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10703/stringobject_format_Lf.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Another rev of the patch now including updates to 2 documentation files:
Doc/c-api/exceptions.rst and Doc/c-api/string.rst. As before the patch is
relative to the source of Python 2.6b1.
Where should test cases for the new formats
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10703/stringobject_format_Lf.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
The tests for PyString_FromFormat are in file Modules/_testcapimodule.c.
Attached is yet another update of the patch, this one also includes 3
tests for the new %f format specification added to file
Modules/_testcapimodule.c.
Adde
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10705/stringobject_format_Lf.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Here is a simple test case, demonstrating the issue.
#include
#include
#include
int main(int argc, char *argv[])
{
printf("%f %d\n", log(-HUGE_VAL), errno);
printf("%f %d\n", log( HUGE_VAL), errno);
}
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Here is another patch for PyString_FromFormat* adding support for 'l' and
'z' type specifications for the '%x' format and an optional '#' to prepend
'0x' to the hex result. In additio
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Right on! With errno = 0; in between both calls:
-Inf 33
Inf 0
/Jean
On Tue, Jun 24, 2008 at 1:17 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
>
> Mark Dickinson <[EMAIL PROTECTED]> added the comment:
>
> O
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Mark,
Take a look at the SUN forum, there is a (long) answer.
<http://forum.java.sun.com/thread.jspa?threadID=5308106&tstart=0>
/Jean
On Tue, Jun 24, 2008 at 3:37 PM, Jean Brouwers <[EMAIL PROTECTED]> wrote:
>
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Unless I am doing something wrong, that flag does not fix the problem.
#include
#include
#include
int main(int argc, char *argv[])
{
errno = 0;
printf("%f %d\n", log(-HUGE_VAL), errno);
errno = 0;
print
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Sorry, the flag *does* make a difference. Ignoring errno, the results for
32- and 64-bit do match.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
The 64-bit version did the right thing, all along. The 32-bit result is
correct only when compiled with option -xlibmieee.
But the latter sets errno value to EDOM and that should be 0, rather
remain unmo
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
3 different Python 2.6b1 builds:
1) 64-bit Python 2.6b1 on Solaris 10 built with SUN C (no -xlibmieee):
Python 2.6b1 (r26b1:64398, Jun 19 2008, 20:27:39) [C] on sunos5
Type "help", "copyright", "credits&quo
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
The patch <http://bugs.python.org/file10754/issue3167.patch> does not
work. The -xlibmieee flag is included in the cc command lines, like
cc -c -xtarget=native -xlibmieee -DNDEBUG -xO5 -I.
However, the resulting build
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Keep in mind also, these Python builds are compiled with the SUN
compilers, i.e. the ./configure command line includes --without-gcc.
If we do change the CC- and LINKFLAGS, those changes should only apply
in that particular case.
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
The 32-but results are the same when built with -xO5.
Python 2.6b1 (r26b1:64398, Jun 28 2008, 10:43:53) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more inf
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
For 32-bit, see the latest posts at <http://bugs.python.org/issue3167>.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Here are the 64-bit results. First with -xO5:
Python 2.6b1 (r26b1:64398, Jun 28 2008, 10:57:27) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> i
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
The SUN compiler versions
> cc -V
cc: Sun C 5.8 2005/10/13
usage: cc [ options] files. Use 'cc -flags' for details
> CC -V
CC: Sun C++ 5.8 2005/10/13
Both define the following symbols:
#define __SUNPRO_C 0x58
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Forgot to mention, both 64-bit builds above includes -xlibmieee in the
BASECFLAGS and LDFLAGS ./configure symbols (not LDSHARED!).
The complete .configure command line was (with OPT adjusted accordingly):
env CCSHARED="-KPIC&qu
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Sorry, my previous post was wrong. The LDSHARED symbol did NOT include -
xlibmieee. Only the BASECFLAGS and the LDFLAGS.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
I applied your patch to freshly updated configure and configure.in files
and ran ./configure --without-gcc on Solaris.
The resulting Makefile has empty BASECFLAGS and LDFLAGS. Here is the
snippet:
# Compiler optio
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
This is pretty bizarre, take a look at the following, 64-bit Pyhon 2.6b1
-xO5.
Python 2.6b1 (r26b1:64398, Jun 28 2008, 12:50:06) [C] on sunos5
Type "help", "copyright", "credits" or "licen
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Trying to isolate and duplicate the problem with c_quot isn't quite
working. See the attached c_quot.c file and the results at the end.
Added file: http://bugs.python.org/file10762/c_quot.c
___
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Yep, that one works. As before, using ./configure --without-gcc ...
BASECFLAGS= -xlibmieee
CFLAGS= $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS)
# Both CPPFLAGS and LDFLAGS need to contain the shell's value for
setup
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
For comparison, 64-bit -xO5 Python build:
Python 2.6b1 (r26b1:64398, Jun 28 2008, 12:50:06) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> i
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
What about this case? Should cmath not produce the same result as math:
>>> math.log(float('-inf'))
Traceback (most recent call last):
File "", line 1, in
ValueError: math domain error
>>> cmath
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
I have not yet been able to duplicate the problem in a smaller test
case, but I did stumble into a fix. Changing the following statement in
the cmath_log function from
if (PyTuple_GET_SIZE(args) == 2)
x = c_
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Attached is a test case which does demonstrate the problem. See the top
of that file. I will post this at the SUN C Forum.
Added file: http://bugs.python.org/file10774/SunC-64bit-xO5-bug.c
___
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10762/c_quot.c
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Jean Brouwers <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10774/SunC-64bit-xO5-bug.c
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
File but showing -xO0 thru -xO5 results.
Added file: http://bugs.python.org/file10775/SunC-64bit-xO5-bug.c
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
Without changing the cmath_log code, another workaround is to compile
Python with optimization level -xO2 or less for 64-bit using Sun C.
___
Python tracker <[EMAIL PROTECTED]>
<http://
Jean Brouwers <[EMAIL PROTECTED]> added the comment:
There is another, perhaps related issue on Solaris. The compiler warns
that function finite is implicitly defined.
Commenting out this line in pyconfig.h as
/* #define HAVE_FINITE 1 */
make that warning go away. If there is no fu
1 - 100 of 199 matches
Mail list logo
