[issue17547] checking whether gcc supports ParseTuple __format__... erroneously returns yes with gcc 4.8
Alex Leach added the comment: I don't think I can tell you anything you don't know already, but ... On Tue, 23 Apr 2013 19:38:18 +0100, Dave Malcolm rep...@bugs.python.org wrote: BTW, is that GCC format checking code available anywhere? Is this what you mean? http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/c-family/c-format.c?annotate=193304pathrev=193304 I got taken straight there from the link you sent, above... Am I right in thinking that it was an out-of-tree patch to GCC, from the pre-plugin days? No idea.. GCC plugins have been around for several years now, though and the patch was only introduced in November. If this patch was applied to any past GCC distributions, I'm sure someone else would have been overwhelmed with warnings and would have mentioned something before now. Either way, it looks like the patch is going to stay. In case you hadn't seen it already, the invoke.texi source file probably has the most descriptive changes:- http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/doc/invoke.texi?r1=193304r2=193303pathrev=193304 KR, Alex -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17547 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17547] checking whether gcc supports ParseTuple __format__... erroneously returns yes with gcc 4.8
Alex Leach added the comment: The configure.ac patch works for me, on x86_64 Arch Linux. I just updated to GCC-4.8.0 and came across an overwhelming number of these warnings when compiling extension modules. Thanks for the simple fix David. Tested on hg branch 2.7; the testsuite completes without error. -- nosy: +Alex.Leach versions: -Python 2.6, Python 2.7, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17547 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4934] tp_del and tp_version_tag undocumented
Alex Leach added the comment: I've just ran into tp_version_tag, when running the boost python testsuite and wondered what it was... Since upgrading to GCC 4.8, I've started to get a lot more warnings with Python extensions, e.g.:- boost/python/opaque_pointer_converter.hpp:122:14: warning: missing initializer for member ‘_typeobject::tp_version_tag’ [-Wmissing-field-initializers] In this instance the testsuite was made to compile with the '-Wextra' flag. The fix was pretty simple; add another zero to the opaque_pointer_convert struct. I have used the following preprocessor macro to test whether or not to do this. Would this be a good way to test for the addition? #if PY_VERSION_HEX = 0x0206 0,/* tp_version_tag */ #endif Cheers, Alex -- nosy: +Alex.Leach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4934 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
Alex Leach beamesle...@gmail.com added the comment: I hadn't tried the `long long` substitution before, but unfortunately I don't think that simple fix quite does the trick. I just checked out libffi from git, and made the following patch:- #$ diff -u ffi64.c ffi64.c.orig --- ffi64.c 2012-07-16 11:38:44.237255615 +0100 +++ ffi64.c.orig2012-07-16 11:38:34.681045084 +0100 @@ -38,7 +38,7 @@ #define MAX_SSE_REGS 8 #ifdef __INTEL_COMPILER -#define UINT128 long long +#define UINT128 __m128 #else #define UINT128 __int128_t #endif It compiles fine, but `make check` returns a lot of FAIL's, and a quite a few of the tests timeout. e.g. FAIL: libffi.special/unwindtest.cc -shared-libgcc -lstdc++ execution test WARNING: program timed out. It's probably also worth mentioning that I'm now using icc version 12.1.4 Cheers, Alex On Monday 16 Jul 2012 09:53:36 Stefan Krah wrote: Stefan Krah stefan-use...@bytereef.org added the comment: Ah, forget that: Alex has apparently already tested that patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4130 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
Alex Leach beamesle...@gmail.com added the comment:
I just had a dig around my cpython build dir, and found an ffi64.c I hacked at
a
while back.
I copied the edits over to the latest libffi git revision, rebuilt, and `make
check` (of libffi) passes all tests. So as far as I can tell the below patch
works, but it is a hack, and I'm sure it could be improved..
Regards to submitting it upstream, I've just written to the libffi-
discuss/sourceware.org mailing list, sending them the below patch also. So it
might work, but you know that GPL clause about coming with no warranty? ;)
HTH,
Alex
libffi-git diff -u src/x86/ffi64.c.orig src/x86/ffi64.c
--- src/x86/ffi64.c.orig2012-07-16 11:38:34.681045084 +0100
+++ src/x86/ffi64.c 2012-07-16 22:34:42.959552750 +0100
@@ -38,7 +38,7 @@
#define MAX_SSE_REGS 8
#ifdef __INTEL_COMPILER
-#define UINT128 __m128
+typedef struct { int64_t m[2]; } __int128_t;
#else
#define UINT128 __int128_t
#endif
@@ -47,7 +47,7 @@
{
/* Registers for argument passing. */
UINT64 gpr[MAX_GPR_REGS];
- UINT128 sse[MAX_SSE_REGS];
+ __int128_t sse[MAX_SSE_REGS];
};
extern void ffi_call_unix64 (void *args, unsigned long bytes, unsigned flags,
@@ -477,10 +477,20 @@
break;
case X86_64_SSE_CLASS:
case X86_64_SSEDF_CLASS:
+#ifdef __INTEL_COMPILER
+ reg_args-sse[ssecount].m[0] = *(UINT64 *) a;
+ reg_args-sse[ssecount++].m[1] = 0;
+#else
reg_args-sse[ssecount++] = *(UINT64 *) a;
+#endif
break;
case X86_64_SSESF_CLASS:
+#ifdef __INTEL_COMPILER
+ reg_args-sse[ssecount].m[0] = *(UINT32 *) a;
+ reg_args-sse[ssecount++].m[1] = 0;
+#else
reg_args-sse[ssecount++] = *(UINT32 *) a;
+#endif
break;
default:
abort();
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4130
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
Alex Leach beamesle...@gmail.com added the comment: It skips 55, sorry, passing 1659. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
Alex Leach beamesle...@gmail.com added the comment: That's the same patch as I attached before actually, so sorry for the spam.. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
Alex Leach beamesle...@gmail.com added the comment: Thanks for the assurance. I found it strange because compilation only fails when building shared binaries. My static build of Python-2.7.3, with icc seems to work fine, except for this libffi issue. Turns out I needed dejagnu to run the tests in libffi's `make check`, which is why it passed before when it shouldn't have. I'll liaise with the libffi authors to try and come up with a working solution. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
Changes by Alex Leach beamesle...@gmail.com: Added file: http://bugs.python.org/file25221/ffi64.c.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
Alex Leach beamesle...@gmail.com added the comment:
Submitting a working patch upstream would make sense.. Just found, downloaded
and tried compiling libffi-3.0.11. The developers have made some changes
towards a solution, but compilation fails with the same error:-
libtool: compile: icc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude
-I../src -DFFI_BUILDING -g -O3 -ansi_alias -Wall -fexceptions -MT
src/x86/ffi64.lo -MD -MP -MF src/x86/.deps/ffi64.Tpo -c ../src/x86/ffi64.c
-fPIC -DPIC -o src/x86/.libs/ffi64.o
../src/x86/ffi64.c(50): error: identifier __m128 is undefined
UINT128 sse[MAX_SSE_REGS];
__m128 is defined in Intel's xmmintrin.h though
[http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/cpp/lin/compiler_c/intref_cls/common/intref_sse_arithmetic.htm].
So I added the necessary include line, which gets a different error:-
libtool: compile: icc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude
-I../src -DFFI_BUILDING -g -O3 -ansi_alias -Wall -fexceptions -MT
src/x86/ffi64.lo -MD -MP -MF src/x86/.deps/ffi64.Tpo -c ../src/x86/ffi64.c
-fPIC -DPIC -o src/x86/.libs/ffi64.o
../src/x86/ffi64.c(481): error: a value of type UINT64={unsigned long} cannot
be assigned to an entity of type __m128
reg_args-sse[ssecount++] = *(UINT64 *) a;
^
../src/x86/ffi64.c(484): error: a value of type UINT32={unsigned int} cannot
be assigned to an entity of type __m128
reg_args-sse[ssecount++] = *(UINT32 *) a;
^
Regarding my previous patch, I'm not convinced it works actually.. It compiles,
and passes the default Python tests, but I get some dodgy behaviour. e.g. when
compiling 2.7.3 with --enable-shared, I get a segfault when compiling the gdbm
module against libdb4.8-dev. Any specific ways of testing the build?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4130
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
Alex Leach beamesle...@gmail.com added the comment: Patch included for Modules/_ctyles/libffi/src/x86/ffi64.c. I've added some include guards around anything necessary to compile with the Intel compiler. This patch is needed to compile the _ctypes module with icc on current Python releases (just successfully compiled 2.7.3, with patch).. -- keywords: +patch nosy: +Alex.Leach Added file: http://bugs.python.org/file25205/ffi64.c.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Alex Leach beamesle...@gmail.com added the comment: I got the same test_commands fail when building a Python2.7.1 which I downloaded yesterday; it's on an FC13 x86_64 server. I've built python2.7 before using a similar machine, but it's not picking up my external libraries on a Sun Grid Engine, leaving me with import errors. Probably problems with the environment ($PYTHONHOME $PYTHONPATH), but playing with these don't fix my batch jobs, so I've decided to build a cross-compiled version, which I've done on a Mac Pro before, but not a linux server, where --with-universal-archs doesn't work. I'm not a guru with using CFLAGS args during compilation, so I think I'll end up compiling it twice (long, I need this to work yesterday), using Jason's configure arguments (that -m32 is the ticket), and taking Jason's wrapper script, modifying it for my home dir. Thanks for posting that Jason!! I'd already started implementing something similar in my batch script, but yours looks much more thorough. Whilst here, I wanted to advocate python a bit. I think it's awesome, and an article that articulates it's awesomeness fairly amusingly, can be found here:- http://www.linuxjournal.com/article/3882 Still, I'm also disappointed with these build problems. I left `make test` running overnight and it had hung, using 100% of a CPU the whole night. I'm not even half-way to getting python compiled... :( Will probably also need to recompile ATLAS as well as numpy / biopython for both archs - no quick or easy feat. -- nosy: +Alex.Leach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Alex Leach beamesle...@gmail.com added the comment: Hey Jason, Thanks for replying so quickly, and on a bank holiday! :) This has completely diverged from the original bug, but whatever.. Thanks for the C wrapper too! It's not appropriate for my build environment, and I know no C, having only got so far as writing a hello world program with it, so I'll probably stick with my bash wrapper script for now. Currently re-compiling python2.7.1 to support i686 machines. The first build wasn't allowing me to compile numpy with the supplied atlas libraries, failing to pick up the extension .so.3 / .so.3.0 which I think has something to do with position independent code, so I'm recompiling this 32 bit python with the following commands:- $ export CFLAGS=-O2 -fPIC $ export CXXFLAGS=$CFLAGS $ OPT=-m32 LDFLAGS=-m32 ./configure --prefix=$HOME/32 Does that seem sensible to you?? The relevant part of my bash wrapper script (for sun grid engine) is then something like:- #!/bin/bash if [[ `uname -m` = x86_64 ]] ; then export PYTHONHOME=$HOME/ else echo arch = `uname -m` export PYTHONHOME=$HOME/32 fi -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11458] tarfile with socket incompatability
Alex Leach beamesle...@gmail.com added the comment: Thanks! =D On Thu, Mar 10, 2011 at 3:46 AM, R. David Murray rep...@bugs.python.orgwrote: R. David Murray rdmur...@bitdance.com added the comment: I believe you are looking for mode 'r|'. -- nosy: +r.david.murray resolution: - works for me stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11458 ___ -- Added file: http://bugs.python.org/file21069/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11458 ___Thanks! =Dbrbrdiv class=gmail_quoteOn Thu, Mar 10, 2011 at 3:46 AM, R. David Murray span dir=ltrlt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;/span wrote:brblockquote class=gmail_quote style=margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex; br R. David Murray lt;a href=mailto:rdmur...@bitdance.com;rdmur...@bitdance.com/agt; added the comment:br br I believe you are looking for mode #39;r|#39;.br br --br nosy: +r.david.murraybr resolution: Â -gt; works for mebr stage: Â -gt; committed/rejectedbr status: open -gt; closedbr divdiv/divdiv class=h5br ___br Python tracker lt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;br lt;a href=http://bugs.python.org/issue11458; target=_blankhttp://bugs.python.org/issue11458/agt;br ___br /div/div/blockquote/divbr ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11458] tarfile with socket incompatability
New submission from Alex Leach beamesle...@gmail.com:
Hi,
I'm trying to parse the contents of tar archives (.tgz) on the fly, and failing
to do so. The tar archives in question have directory hierarchies, and only if
a TarInfo object is a file (.isreg() ) will I try and read it's contents.
I figured a sensible idea would be to pass a socket(.makefile()) object to the
fileobj attribute of tarfile.open. This doesn't work because a socket file
descriptor does not have a tell() method. I understand that a socket object
shouldn't need to have a tell method, but why should the fileobj passed to
tarfile.open need it?
Code:-
def get_headers( self, file_name ):
sock = socket.socket()
sock.bind(('localhost',0))
fd = sock.makefile()
handle = tarfile.open( file_name,'r',fileobj=fd ) # This line breaks
I'm currently testing on Python v2.6.6 EPD 6.3-2 64 bit, on an Autumn 2010 Mac
Pro.
My dirty bug-fix idea is to subclass tarfile.TarFile, and give it a tell()
method, to just return 0. I don't want to have to do that. Any alternative
suggestions would be greatly appreciated.
Cheers,
Alex
--
components: Extension Modules
messages: 130482
nosy: Alex.Leach
priority: normal
severity: normal
status: open
title: tarfile with socket incompatability
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11458
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
