On Wed, Aug 29, 2012 at 01:22:59PM +0200, Matthias Klose wrote:
> there is hardly any information in this report besides "it doesn't work with
> gcc-4.7 -O2".
>
> Please track this down to some file which you claim is miscompiled, by combining
> object files built with -O1/-O2 or 4.6/4.7, then try to track this down to some
> -O2 -fno-<option>, which is enabled by -O2 by default.
As stated in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678122;msg=40
and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678122;msg=45 I've
already tried this.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678122;msg=20 also
showed the section of the code causing the problem.
> Also please check with
> gcc-snapshot.
>
> it could be a compiler error, or just a bug in vim exposed by more aggressive
> optimization options (so maybe check the warnings too).
70 static PyObject *
71 OutputWrite(PyObject *self, PyObject *args)
72 {
73 int len;
74 char *str = NULL;
75 int error = ((OutputObject *)(self))->error;
76
77 if (!PyArg_ParseTuple(args, "et#", ENC_OPT, &str, &len))
78 return NULL;
A patch was recently posted to the Vim mailing list changing "int len;" to
"Py_ssize_t len;" and that fixes the problem, since Vim is #define'ing
PY_SSIZE_T_CLEAN.
So, this does appear to be a bug in how Vim was using the Python API,
but why does this work with GCC 4.6 and silently cause a crash with GCC
4.7?
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan@debian.org>
Attachment:
signature.asc
Description: Digital signature