[issue27725] Use Py_SIZE(x) instead of x->ob_size

STINNER Victor added the comment: > However, compiling ONLY the file Objects/longobject.c with -qalias=noansi did > fix the issue on AIX. That could be the same on Linux. Nobody asked to only set the compiler file to only this file. As we said, the issue is sprayed in all the C code base. The

[issue27725] Use Py_SIZE(x) instead of x->ob_size

REIX Tony added the comment: OK. However, compiling ONLY the file Objects/longobject.c with -qalias=noansi did fix the issue on AIX. That could be the same on Linux. I haven't tried to use Py_SIZE() in all places where it should be used. Now trying to figure out why GCC behaves worst than

[issue27725] Use Py_SIZE(x) instead of x->ob_size

Stefan Krah added the comment: Agreed, the changes are too big for 2.7. -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker

[issue27725] Use Py_SIZE(x) instead of x->ob_size

STINNER Victor added the comment: I mean that fixing ob->ob_size in Objects/longobject.c is not enough. You should also fix C structures and fix all other C files in the code base... It's too late for such major refactoring in Python 2. -- ___

[issue27725] Use Py_SIZE(x) instead of x->ob_size

STINNER Victor added the comment: I suggest to close this issue. Aliasing issues are complex and simply cannot be fixed in Python 2. The root issue has been fixed in Python 3, it required to change the main C structures of Python objects. The fix for your issue to already known, use

[issue27725] Use Py_SIZE(x) instead of x->ob_size

REIX Tony added the comment: With XLC v13 -O2, using -qalias=noansi for building Objects/longobject.o only and not for all the other .o files did fix the 10 more failed tests I see with -O2 compared to -O0 (7-8 failed tests). So, ANSI-aliasing in Objects/longobject.c is the issue. About

[issue27725] Use Py_SIZE(x) instead of x->ob_size

Stefan Krah added the comment: On Thu, Aug 11, 2016 at 09:29:44AM +, REIX Tony wrote: > -fno-strict-aliasing -fwrapv for gcc > > So, that means that you would get better performance if you applied on Python > v2.7 what Python v3.5 did about Py_SIZE(x) . > However, there are probably other

[issue27725] Use Py_SIZE(x) instead of x->ob_size

REIX Tony added the comment: Thanks a lot Stefan, that should completely explain my issues. -fno-strict-aliasing -fwrapv for gcc So, that means that you would get better performance if you applied on Python v2.7 what Python v3.5 did about Py_SIZE(x) . However, there are probably other places

[issue27725] Use Py_SIZE(x) instead of x->ob_size

Stefan Krah added the comment: In 2.7 we use -fno-strict-aliasing and -fwrapv for gcc. I think it is probably required to use the equivalent options for xlc. These are examples of things that have been cleaned up in 3.x. 2.7 actually relies on these options. --

[issue27725] Use Py_SIZE(x) instead of x->ob_size

Changes by Raymond Hettinger : -- nosy: +loewis, tim.peters ___ Python tracker ___

[issue27725] Use Py_SIZE(x) instead of x->ob_size

REIX Tony added the comment: Hi Raymond I've got several email exchanges with the IBM XLC expert. From his own study of my issue, his conclusion is that this kind of Python v2 coding is not ANSI-aliasing safe. It seems that there is a standard that requires C code to NOT do some kinds of

[issue27725] Use Py_SIZE(x) instead of x->ob_size

Raymond Hettinger added the comment: I'm not clear on how non-use of the macro is causing your observed failures or whether that is due to a compiler bug. That said, I don't see any downside to using Py_SIZE everywhere it is applicable. -- ___

[issue27725] Use Py_SIZE(x) instead of x->ob_size

Changes by SilentGhost : -- components: +Interpreter Core nosy: +facundobatista, mark.dickinson, rhettinger, skrah ___ Python tracker

[issue27725] Use Py_SIZE(x) instead of x->ob_size

New submission from REIX Tony: I'm porting Python 2.7.* on AIX. I am now using a version 13.1.3.2 of XLC. I was previously using version 12.1.0.14 . It appears that this new compiler shows a potential issue in Python v2 code. This issue seems to appear when -O2 is used. I was porting Python