| View previous topic :: View next topic |
| Author |
Message |
Codec & Electron
n00b
Joined: 10 Jul 2002
Posts: 43
Location: Düsseldorf, Germany
|
 Posted: Sat Dec 21, 2002 5:33 pm Post subject: Python-2.2.2 bug? |
 |
|
Hi all,
expressions like the following cause errors or wrong results (only with Python-2.2.2):
Python 2.2.2 (#1, Dec 21 2002, 18:16:10)
[GCC 3.2.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> int(1.11)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
OverflowError: float too large to convert
[9815 refs]
>>> int(1.1)
0
[9817 refs]
As you can see, I've compiled Python with debug information enabled (the same is true for regular versions). It should not be a problem that is caused by compiler optimizations.
Then I'm not sure if this is really a problem related to Gentoo, since these errors occur no matter if I use the ebuild--version or another one that I've compiled my own. However Python-2.1.3 works fine.
Can anyone confirm such problems with Gentoo 1.4rc and Python-2.2.2?
Thanks!
Kind regards,
C&E |
|
| Back to top |
|
 |
Codec & Electron
n00b
Joined: 10 Jul 2002
Posts: 43
Location: Düsseldorf, Germany
|
| Posted: Sun Dec 22, 2002 12:44 pm Post subject: Re: Python-2.2.2 bug? |
|
|
After searching through Python's source code, I recognized, that the funtion float_int() in floatobject.c is causing my trouble and its implementation has changed compared with Python-2.1.3. It seems, as if he call to modf() returns wrong results and to be sure I've tested modf() with the following C testfile:
| Code: | #include <stdio.h>
#include <math.h>
int main()
{
double x = 1.1;
double y;
printf("Calling modf() for %f\n", x);
printf("fractional part = %f\ninteger part = %f\n",
modf(x, &y), y);
return 0;
}
|
The expected output should look like this:
| Code: | Calling modf() for 1.100000
fractional part = 0.100000
integer part = 1.000000
|
but GCC actually gave me:
| Code: | $ gcc test.c -o test
$ ./test
Calling modf() for 1.100000
fractional part = 1.100000
integer part = -0.000000
|
To double-check I switched to Win2k and compiled with MinGW, but it did
not much better (at least the signs are correct):
| Code: | C:\Temp>C:\mingw\bin\gcc test.c -o test.mingw.exe
C:\Temp>test.mingw
Calling modf() for 1.100000
fractional part = 0.100000
integer part = 0.000000
|
Only lcc on Win2k performed as expected:
| Code: | C:\Temp>C:\lcc\bin\lc test.c
C:\Temp>test
Calling modf() for 1.100000
fractional part = 0.100000
integer part = 1.000000
|
In summary it looks like the trouble is GCC related. Replacing float_int() in Python-2.2.2 with float_int() from Python-2.1.3 fixes the problem, because there is no modf() call in the 2.1.3 version. However I will try to locate the error in GCC. At least the Python implementation does not seem to be responsible for all this, but a GCC bug is not very pleasant either. 
Kind regards,
C&E |
|
| Back to top |
|
|
sertsa
n00b
Joined: 21 May 2002
Posts: 49
Location: High Desert
|
| Posted: Mon Dec 23, 2002 6:25 am Post subject: |
|
|
No probs here, same setup as you:
| Code: |
Python 2.2.2 (#1, Dec 10 2002, 04:26:58)
[GCC 3.2.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> int(1.11)
1
|
|
|
| Back to top |
|
|
rac
Bodhisattva
Joined: 30 May 2002
Posts: 6553
Location: Japanifornia
|
| Posted: Mon Dec 23, 2002 6:27 am Post subject: |
|
|
Could you two compare CFLAGS?
_________________
For every higher wall, there is a taller ladder |
|
| Back to top |
|
|
Codec & Electron
n00b
Joined: 10 Jul 2002
Posts: 43
Location: Düsseldorf, Germany
|
| Posted: Mon Dec 23, 2002 10:37 am Post subject: |
|
|
| rac wrote: | | Could you two compare CFLAGS? |
The problem occurs regardless of whether I use ebuilds or not. A Python-2.2.2 compiled by my own (./configure && make && make install) shows the same errors. I conclude, that the problem is not Python's fault. It has to be an GCC or glibc issue which I could'nt resolve for now.
BTW: I'm in Christmas holidays for the next couple of days. I will resume next week ...
Kind regards,
C&E |
|
| Back to top |
|
|
Codec & Electron
n00b
Joined: 10 Jul 2002
Posts: 43
Location: Düsseldorf, Germany
|
| Posted: Mon Dec 30, 2002 3:10 pm Post subject: |
|
|
| Codec & Electron wrote: | | I conclude, that the problem is not Python's fault. It has to be an GCC or glibc issue which I could'nt resolve for now. |
It turned out that this is indeed the case. Compiling glibc-2.3.1 with gcc-3.2.1 causes havoc as several bug reports and threads in this forum show. I recompiled glibc-2.3.1 with gcc-3.2 and then Python-2.2.2 and everything worked as expected.
Kind regards and happy new year!
C&E |
|
| Back to top |
|
|
jkowing
n00b
Joined: 13 Feb 2003
Posts: 1
|
| Posted: Thu Feb 13, 2003 5:27 pm Post subject: |
|
|
FWIW, I had the exact same problem with
sys-libs/glibc-2.3.1-r2
sys-devel/gcc-3.2.1-r6
dev-lang/python-2.2.2
Instead of downgrading to gcc-3.2 I tried changing my CFLAGS in /etc/make.conf from:
CFLAGS='-march=pentium4 -O2 -pipe'
to:
CFLAGS='-march=i686 -O2 -pipe'
and then recompiled glibc-3.2.1 and this solved the problem. I guess this is probably a gcc pentium4 specific bug perhaps? |
|
| Back to top |
|
|
Heretic
Tux's lil' helper
Joined: 03 Jul 2002
Posts: 114
Location: Austin, TX USA
|
| Posted: Thu Mar 20, 2003 1:31 pm Post subject: Re: Python-2.2.2 bug? |
|
|
| Codec & Electron wrote: |
| Code: | #include <stdio.h>
#include <math.h>
int main()
{
double x = 1.1;
double y;
printf("Calling modf() for %f\n", x);
printf("fractional part = %f\ninteger part = %f\n",
modf(x, &y), y);
return 0;
}
|
| Code: | $ gcc test.c -o test
$ ./test
Calling modf() for 1.100000
fractional part = 1.100000
integer part = -0.000000
|
|
Can you still reproduce this? I tried and I got: | Code: | palace tmp # gcc -march=pentium4 -O2 -msse2 test.c
palace tmp # ./a.out
Calling modf() for 1.100000
fractional part = 0.100000
integer part = 1.000000 |
However, I still get errors in Python. I can't
| Code: | | python -c 'int(10000.3);' |
When I compile Python with those same flags.
[code] |
|
| Back to top |
|
|
Codec & Electron
n00b
Joined: 10 Jul 2002
Posts: 43
Location: Düsseldorf, Germany
|
| Posted: Wed Mar 26, 2003 9:41 am Post subject: Re: Python-2.2.2 bug? |
|
|
| Heretic wrote: | Can you still reproduce this? I tried and I got: | Code: | palace tmp # gcc -march=pentium4 -O2 -msse2 test.c
palace tmp # ./a.out
Calling modf() for 1.100000
fractional part = 0.100000
integer part = 1.000000 |
However, I still get errors in Python. I can't
| Code: | | python -c 'int(10000.3);' |
When I compile Python with those same flags. |
No I can't reproduce this anymore. However I changed my CFLAGS quite a long time ago after reading in /etc/make.conf:
| Quote: | # CPU types supported in gcc-3.2 and higher: athlon-xp, athlon-mp,
# athlon-tbird, athlon, k6, k6-2, k6-3, i386, i486, i586 (Pentium), i686
# (PentiumPro), pentium, pentium-mmx, pentiumpro, pentium2 (Celeron), pentium3.
# Note that Gentoo Linux 1.4 and higher include at least gcc-3.2.
# ATHLON-4 will generate invalid SSE instructions; use 'athlon' instead.
# PENTIUM4 will generate invalid instructions; use 'pentium3' instead.
|
My CFLAGS are very modest: CFLAGS="-march=pentium3 -O3 -pipe". I have no additional information about pentium4 related bugs in gcc but you might try recompiling glibc, gcc and python with -march=pentium3 as jkowing did it according to his post. I think it should solve your problem.
Kind regards,
C&E |
|
| Back to top |
|
|
Heretic
Tux's lil' helper
Joined: 03 Jul 2002
Posts: 114
Location: Austin, TX USA
|
| Posted: Wed Mar 26, 2003 2:09 pm Post subject: |
|
|
| Compiling glibc and python with -mcpu=pentium4 -msse -mmmx -mfpmath=sse -O2 and everything seems to be fine. No double precisions vector ops ie -msse2 |
|
| Back to top |
|
|
pYrania
Retired Dev
Joined: 27 Oct 2002
Posts: 650
Location: Cologne - Germany
|
| Posted: Sun May 04, 2003 5:56 pm Post subject: |
|
|
| Code: | $ python -c 'int(10000.3);'
Traceback (most recent call last):
File "<string>", line 1, in ?
OverflowError: float too large to convert |
well, this happens with -march=pentium4, pentium3 and even i686.
_________________
Markus Nigbur |
|
| Back to top |
|
|
Heretic
Tux's lil' helper
Joined: 03 Jul 2002
Posts: 114
Location: Austin, TX USA
|
| Posted: Sun May 04, 2003 6:22 pm Post subject: |
|
|
| pYrania wrote: | | Code: | $ python -c 'int(10000.3);'
Traceback (most recent call last):
File "<string>", line 1, in ?
OverflowError: float too large to convert |
well, this happens with -march=pentium4, pentium3 and even i686. |
No it doesn't. You have to emerge both glibc and python again after adjusting your CFLAGS. |
|
| Back to top |
|
|
pYrania
Retired Dev
Joined: 27 Oct 2002
Posts: 650
Location: Cologne - Germany
|
| Posted: Sun May 04, 2003 7:45 pm Post subject: |
|
|
oh sorry, did just warp the part of glibc. my fault.
reemerging glibc at the moment. guess it will work then.
_________________
Markus Nigbur |
|
| Back to top |
|
|
azote
Guru
Joined: 17 Sep 2002
Posts: 415
|
| Posted: Wed May 14, 2003 5:31 am Post subject: |
|
|
| jkowing wrote: | FWIW, I had the exact same problem with
sys-libs/glibc-2.3.1-r2
sys-devel/gcc-3.2.1-r6
dev-lang/python-2.2.2
Instead of downgrading to gcc-3.2 I tried changing my CFLAGS in /etc/make.conf from:
CFLAGS='-march=pentium4 -O2 -pipe'
to:
CFLAGS='-march=i686 -O2 -pipe'
and then recompiled glibc-3.2.1 and this solved the problem. I guess this is probably a gcc pentium4 specific bug perhaps? |
Thanks!!! this really help me ...
Now I can run bittorrent 
_________________
contact me -> azote@mail.i2p
What do you want to emerge today?
if you think that a person is normal, it is because you do not know them well |
|
| Back to top |
|
|
IamtheOne
Apprentice
Joined: 27 Sep 2002
Posts: 158
Location: Iowa
|
| Posted: Wed May 21, 2003 12:29 pm Post subject: |
|
|
This seems to be fixed in gcc-3.2.3
Before I too got the error but it has disappeared since I recompiled gcc,glibc, and python with 3.2.3. Don't know if you need to do all of those, but I like to be safe 
| Code: | | CFLAGS="-march=pentium4 -pipe -O3 -fomit-frame-pointer" |
happy compiling. |
|
| Back to top |
|
|
|
Portage & Programming
