Re: [Python-Dev] mingw32 and gc-header weirdness

On 7/24/09 5:16 AM, Roumen Petrov wrote: Christian Tismer wrote: ... Did the crash disappear is you add "__attribute__((aligned(8)))" after variable dummy ? Did not try. But the proposed addition of a double does it, see the dev list. cheers - chris -- Christian Tismer :^)

Re: [Python-Dev] mingw32 and gc-header weirdness

On 7/27/09 12:48 AM, Christian Heimes wrote: Christian Tismer wrote: We should keep Martin's hint in mind, that Python 4 could place the gc header at the end of structures, instead. Wow, 3.1 just came out and we already have the first PEP for Python 4k? :) Christian Maybe it's even possible

Re: [Python-Dev] mingw32 and gc-header weirdness

Christian Tismer wrote: > We should keep Martin's hint in mind, that Python 4 could place > the gc header at the end of structures, instead. Wow, 3.1 just came out and we already have the first PEP for Python 4k? :) Christian ___ Python-Dev mailing list

Re: [Python-Dev] mingw32 and gc-header weirdness

On 7/25/09 7:11 AM, Neil Hodgson wrote: Martin v. Löwis: I propose to add another (regular) double into the union. Adding a regular double as a second dummy gives the same sizes and alignments with Mingw or MSVC as the original definition with MSVC: Great (checked that, too) This makes

Re: [Python-Dev] mingw32 and gc-header weirdness

>Maximum alignment currently on x86 is 16 bytes for SSE vector > types. Next year AVX will add 32 byte types and while they are > supposed to work OK with 16 byte alignment, performance will be better > with 32 byte alignment. That doesn't really matter. What matters is the platform's ABI, i.e

Re: [Python-Dev] mingw32 and gc-header weirdness

Martin v. Löwis: > Yes: alignof(PyGC_HEAD) would be specified as being the maximum > alignment on a platform; sizeof(PyGC_HEAD) would be frozen. Maximum alignment currently on x86 is 16 bytes for SSE vector types. Next year AVX will add 32 byte types and while they are supposed to work OK with

Re: [Python-Dev] mingw32 and gc-header weirdness

> We could add a PY_LONG_LONG to the mix just in case. > By the way, will this kind of thing be frozen by the PEP ABI? Yes: alignof(PyGC_HEAD) would be specified as being the maximum alignment on a platform; sizeof(PyGC_HEAD) would be frozen. The actual content would not be frozen, i.e. it could b

Re: [Python-Dev] mingw32 and gc-header weirdness

>> Why is that difficult? It's sizeof(PyGC_Head). > > Is it enough to correctly propagate the alignment for, say, a long double in > the following PyObject? I'm sorry, I'm not enough of a C lawyer. Yes, sizeof must always be a multiple of the alignment. Otherwise, array elements would be misalign

Re: [Python-Dev] mingw32 and gc-header weirdness

Antoine Pitrou pitrou.net> writes: > > We could add a PY_LONG_LONG to the mix just in case. > By the way, will this kind of thing be frozen by the PEP ABI? (I meant the ABI PEP, sorry) ___ Python-Dev mailing list Python-Dev@python.org http://mail.py

Re: [Python-Dev] mingw32 and gc-header weirdness

Neil Hodgson gmail.com> writes: > > typedef union _gc_head { >struct { >union _gc_head *gc_next; >union _gc_head *gc_prev; >Py_ssize_t gc_refs; >} gc; >long double dummy; /* force worst-case alignment */ >double dumm

Re: [Python-Dev] mingw32 and gc-header weirdness

Martin v. Löwis: > I propose to add another (regular) double into the union. Adding a regular double as a second dummy gives the same sizes and alignments with Mingw or MSVC as the original definition with MSVC: typedef union _gc_head { struct { union _gc_head *gc_next;

Re: [Python-Dev] mingw32 and gc-header weirdness

Martin v. Löwis v.loewis.de> writes: > > > In addition to that union, we should also have a particular mechanism to compute > > what the proper offset should be between the PyGC_Head and the PyObject. > > Why is that difficult? It's sizeof(PyGC_Head). Is it enough to correctly propagate the al

Re: [Python-Dev] mingw32 and gc-header weirdness

> For that reason, I don't like the addition of the opaque header > too much. If there were an option to make the header explicit, > we would not have to round up the object size to a multiple > of (8, 16), but could arrange embedded doubles as they fit the best. We could add the gc head *after* t

Re: [Python-Dev] mingw32 and gc-header weirdness

> Antoine Pitrou pitrou.net> writes: >> In any case, you seem to be right on this particular point: the PyGC_Head >> union >> should probably contain a "double" alternative in addition to the "long >> double" >> (and perhaps even a "long long" one). > > Sorry, I realize that this doesn't really

Re: [Python-Dev] mingw32 and gc-header weirdness

>> This may not be recognized so far, because there is no builtin >> GC-enabled type that embeds a double. >> But if you create such a type, then the double will be correctly >> aligned in your object's structure, but then, when the object >> gets allocated, it is misaligned, because the header siz

Re: [Python-Dev] mingw32 and gc-header weirdness

> To Martin: So I disagree. The gc header is not responsible for > alignment in the first place, but to propagate it, correctly. I think we are in agreement in this respect. That's the whole point of the long double: to make the gc head's alignment the maximum alignment on that platform > And thi

Re: [Python-Dev] mingw32 and gc-header weirdness

Antoine Pitrou wrote: Antoine Pitrou pitrou.net> writes: Roumen Petrov roumenpetrov.info> writes: Antoine Pitrou wrote: In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes (!!). And alignment is ? 16 bytes as well. This is probably why, by the way, a PyGC_Head takes onl

Re: [Python-Dev] mingw32 and gc-header weirdness

Antoine Pitrou pitrou.net> writes: > > Roumen Petrov roumenpetrov.info> writes: > > > > Antoine Pitrou wrote: > > > > > > In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes > > > (!!). > > > > And alignment is ? > > 16 bytes as well. This is probably why, by the way, a P

Re: [Python-Dev] mingw32 and gc-header weirdness

Roumen Petrov roumenpetrov.info> writes: > > Antoine Pitrou wrote: > > > > In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes (!!). > > And alignment is ? 16 bytes as well. ___ Python-Dev mailing list Python-Dev@python.org http:

Re: [Python-Dev] mingw32 and gc-header weirdness

Antoine Pitrou wrote: Christian Tismer stackless.com> writes: Well, I doubt that a 12 byte long double causes any other alignment but 4. In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes (!!). And alignment is ? ___ Python-De

Re: [Python-Dev] mingw32 and gc-header weirdness

Christian Tismer wrote: Hi all, I was hacking to get mingw32 builds of psyco to work and found a pretty weird thing: I used mingw32 (stable distro) to build the psyco extension on top of standard python2.6, built with Visual Studio, and got weird crashes. The reason is in objimpl.h: typedef u

Re: [Python-Dev] mingw32 and gc-header weirdness

Christian Tismer stackless.com> writes: > > Well, I doubt that a 12 byte long double causes any other > alignment but 4. In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes (!!). Regards Antoine. ___ Python-Dev mailing list Python

Re: [Python-Dev] mingw32 and gc-header weirdness

On 7/23/09 2:27 PM, Antoine Pitrou wrote: Christian Tismer stackless.com> writes: ... I'm not sure a double aligned on a 4-byte boundary is "misaligned" on a x86 CPU. I'm also not sure. Anyway, the result was neither intended nor expected, I guess. Alignment is primarily important to avo

Re: [Python-Dev] mingw32 and gc-header weirdness

Antoine Pitrou pitrou.net> writes: > > In any case, you seem to be right on this particular point: the PyGC_Head > union > should probably contain a "double" alternative in addition to the "long > double" > (and perhaps even a "long long" one). Sorry, I realize that this doesn't really address

Re: [Python-Dev] mingw32 and gc-header weirdness

Christian Tismer stackless.com> writes: > > The point is: The GC header is a structure invisible to the "real" > gc allocated objects. It is opaquely prepended to every gc aware > object. Therefore, it *needs* to have the correct size, in order > to propagate its (already correct) alignment to th

Re: [Python-Dev] mingw32 and gc-header weirdness

On 7/23/09 2:04 AM, Antoine Pitrou wrote: Christian Tismer stackless.com> writes: Despite the fact that Python probably has to be changed: If it is true then all the 32-bit Linux Pythons have a 12 byte GC head, IOW they are *all* badly aligned. Why are they badly aligned? The fact that long

Re: [Python-Dev] mingw32 and gc-header weirdness

2009/7/23 David Cournapeau : > On Thu, Jul 23, 2009 at 6:49 PM, Paul Moore wrote: >> 2009/7/22 Christian Tismer : >>> Maybe the simple solution is to prevent building extensions >>> with mingw, if the python executable was not also built with it? >>> Then, all would be fine I guess. >> >> I have ne

Re: [Python-Dev] mingw32 and gc-header weirdness

On Thu, Jul 23, 2009 at 6:49 PM, Paul Moore wrote: > 2009/7/22 Christian Tismer : >> Maybe the simple solution is to prevent building extensions >> with mingw, if the python executable was not also built with it? >> Then, all would be fine I guess. > > I have never had problems in practice with ext

Re: [Python-Dev] mingw32 and gc-header weirdness

Paul Moore wrote: > 2009/7/22 Christian Tismer : >> Maybe the simple solution is to prevent building extensions >> with mingw, if the python executable was not also built with it? >> Then, all would be fine I guess. > > I have never had problems in practice with extensions built with mingw > rathe

Re: [Python-Dev] mingw32 and gc-header weirdness

2009/7/22 Christian Tismer : > Maybe the simple solution is to prevent building extensions > with mingw, if the python executable was not also built with it? > Then, all would be fine I guess. I have never had problems in practice with extensions built with mingw rather than MSVC - so while I'm no

Re: [Python-Dev] mingw32 and gc-header weirdness

Christian Tismer stackless.com> writes: > > Despite the fact that Python probably has to be changed: > If it is true then all the 32-bit Linux Pythons have a 12 > byte GC head, IOW they are *all* badly aligned. Why are they badly aligned? The fact that long double is 12 bytes long doesn't mean i

Re: [Python-Dev] mingw32 and gc-header weirdness

>> What do you propose for doing proper alignment, then? > > May be "void* dummy[4]" is better for force alignment ? That would have the same alignment as a single pointer. > What about alignment on platforms with pointers > 32 bit ? The C compiler will choose the alignment of the union to be t

Re: [Python-Dev] mingw32 and gc-header weirdness

Roumen Petrov wrote: > Martin v. Löwis wrote: > [SNIP] >> No. tim_one changed it to be long double in r25454 to support some >> system that Dave Abrahams uses, so it needs to stay that way :-) >> >> However, we can certainly acknowledge that this is a bug in MingW, >> and special case it. Either in

Re: [Python-Dev] mingw32 and gc-header weirdness

Christian Tismer wrote: On 7/22/09 4:56 PM, Roumen Petrov wrote: Martin v. Löwis wrote: [SNIP] No. tim_one changed it to be long double in r25454 to support some system that Dave Abrahams uses, so it needs to stay that way :-) However, we can certainly acknowledge that this is a bug in MingW,

Re: [Python-Dev] mingw32 and gc-header weirdness

On 7/22/09 5:17 PM, David Cournapeau wrote: On Thu, Jul 23, 2009 at 4:40 AM, Antoine Pitrou wrote: The size of long double is also 12 under 32-bit Linux. Perhaps mingw disagrees with Visual Studio Yes, mingw and VS do not have the same long double type. This has been the source of some probl

Re: [Python-Dev] mingw32 and gc-header weirdness

On Thu, Jul 23, 2009 at 4:40 AM, Antoine Pitrou wrote: > > The size of long double is also 12 under 32-bit Linux. Perhaps mingw disagrees > with Visual Studio Yes, mingw and VS do not have the same long double type. This has been the source of some problems in numpy as well, since mingw uses the

Re: [Python-Dev] mingw32 and gc-header weirdness

On 7/22/09 4:56 PM, Roumen Petrov wrote: Martin v. Löwis wrote: [SNIP] No. tim_one changed it to be long double in r25454 to support some system that Dave Abrahams uses, so it needs to stay that way :-) However, we can certainly acknowledge that this is a bug in MingW, and special case it. Eith

Re: [Python-Dev] mingw32 and gc-header weirdness

Martin v. Löwis wrote: [SNIP] No. tim_one changed it to be long double in r25454 to support some system that Dave Abrahams uses, so it needs to stay that way :-) However, we can certainly acknowledge that this is a bug in MingW, and special case it. Either introduce a symbolic type gchead_align_

Re: [Python-Dev] mingw32 and gc-header weirdness

Christian Tismer wrote: Hi all, I was hacking to get mingw32 builds of psyco to work and found a pretty weird thing: I used mingw32 (stable distro) to build the psyco extension on top of standard python2.6, built with Visual Studio, and got weird crashes. The reason is in objimpl.h: typedef u

Re: [Python-Dev] mingw32 and gc-header weirdness

> Is that considered a mingw bug? Perhaps. I can't test right now: *if* VS has a long double type that is smaller, it is apparently an ABI violation for mingw to not follow VS. It appears that other people also consider it a bug: http://www.velocityreviews.com/forums/showpost.php?p=1514923&postco

Re: [Python-Dev] mingw32 and gc-header weirdness

Hi, > I used mingw32 (stable distro) to build the psyco extension > on top of standard python2.6, built with Visual Studio, > and got weird crashes. > > The reason is in objimpl.h: > > typedef union _gc_head { > struct { > union _gc_head *gc_next; > union _gc_he

[Python-Dev] mingw32 and gc-header weirdness

Hi all, I was hacking to get mingw32 builds of psyco to work and found a pretty weird thing: I used mingw32 (stable distro) to build the psyco extension on top of standard python2.6, built with Visual Studio, and got weird crashes. The reason is in objimpl.h: typedef union _gc_head { s