Martin v. Löwis added the comment: If you are curious, we could now try to find out what precisely goes wrong. The procedure would be this
* after each step, check whether the problem still occurs a) resolve the includes manually, then strip everything that isn't needed. This could start with fastsearch.h and find.h; then remove everything that refers to Python.h (i.e. replace Py_ssize_t with ssize_t, Py_LOCAL_INLINE with static inline, and so on), then remove Python.h b) try simplifying the code, e.g. replace str_len and sub_len with their (constant) values, drop the sub_len == 0 block, and so on. c) when further simplification is not possible (while keeping the actual error), start looking at the assembler code. Alternatively, sent this or some further-simplified version to Intel (assuming they have some kind of bug-reporting channel for icc). With my compiler-vendor's hat on, I'd like to get a test case for bad code generation that comes as a single file, with no includes; for gcc, the request is to submit preprocessor output. Assuming this is too much effort, I'll close this as "won't fix - third party". ---------- resolution: -> wont fix status: open -> closed versions: +3rd party -Python 2.5 __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1084> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
