I have just encountered a strange bug affecting Python 2.5.1 on an
x86_64 Linux, but only when compiled with the Intel C Compiler (ICC)
10.0, not a GCC-compiled Python. On my Intel-compiled one, which
otherwise seems to work fine, ''.find() works incorrectly.

I have narrowed down the issue to the simple test case

   "foo2/**bar**/".find ("/**bar**/")

Observe: On a GCC-compiled Python 2.5.1, the command works as
expected by returning 4:

  [c705213@hc-ma tmp]$ /usr/site/hc-2.6/python/gnu/2.5.1/bin/python2.5
  Python 2.5.1 (r251:54863, Aug 30 2007, 16:21:23)
  [GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> print "foo2/**bar**/".find ("/**bar**/")
  4

On my Python 2.5.1 installation which was compiled from source with the
Intel C Compiler (ICC) for Linux, version 10.0, '-1' is returned:

  [c705213@hc-ma tmp]$ /usr/site/hc-2.6/python/intel/2.5.1/bin/python2.5
  Python 2.5.1 (r251:54863, Aug 30 2007, 16:20:06)
  [GCC Intel(R) C++ gcc 3.4 mode] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> print "foo2/**bar**/".find ("/**bar**/")
  -1

What could have possibly gone wrong here? Admittedly, this smacks more
of a bug in icc than in Python, but I report it here, as I feel at loss
of what else to do with it.

Obvious first question: Does anyone else out here have an ICC-compiled
Python handy  to check whether the bug reproduces elsewhere?

Any idea what kind of oddity I have stumbled over here? Obviously, it
could simply be that something went wrong when compiling Python from
source with ICC, but it should not happen that the interpreter
nebertheless starts up and fails only silently.

Additional information:

- I have stumbled over the problem when trying to install Numpy 1.0.3.1,
as the built failed at the point where a script 'conv_template.py',
which is part of NumPy's installtion system, is started to do some
pattern replacements in a file called 'scalartypes.inc.src'. My test
case is reduced from this script.

- The system is the master node of a compute cluster with AMD Opteron
CPUs. The cluster is not involved, all was done on the master node. The
box runs RedHat Enterprise Linux 4.0 Advanced Server. It replies to
'uname -a' with:
   Linux hc-ma.uibk.ac.at 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 17:13:42
EST 2007 x86_64 x86_64 x86_64 GNU/Linux

- The dynamic dependencies of the GCC-compiled and the ICC-compiled
Python binaries are:
[c705213@hc-ma tmp]$ ldd /usr/site/hc-2.6/python/gnu/2.5.1/bin/python2.5
        libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000003702900000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003701d00000)
        libutil.so.1 => /lib64/libutil.so.1 (0x0000003703900000)
        libm.so.6 => /lib64/tls/libm.so.6 (0x0000003701b00000)
        libc.so.6 => /lib64/tls/libc.so.6 (0x0000003701800000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003701600000)
[c705213@hc-ma tmp]$ ldd /usr/site/hc-2.6/python/intel/2.5.1/bin/python2.5
        libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000003702900000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003701d00000)
        libutil.so.1 => /lib64/libutil.so.1 (0x0000003703900000)
        libimf.so => /usr/site/hc-2.6/intel/10.0/cc/lib/libimf.so
(0x0000002a95579000)
        libm.so.6 => /lib64/tls/libm.so.6 (0x0000003701b00000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003705800000)
        libc.so.6 => /lib64/tls/libc.so.6 (0x0000003701800000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003701600000)

- The precise revision of Python is "Python 2.5.1 (r251:54863)".

- The test case ceases to show failure if the string is only slightly
altered, e.g. if the word 'foo', the word 'bar' or the one of the
asterisks or one of the slashes is cut out in both search and target string.