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
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
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
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 :^)
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 this
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 size is not
Antoine Pitrou solipsis at 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
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* the
Martin v. Löwis martin at 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
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 misaligned.
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 be
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.
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
Antoine Pitrou wrote:
Christian Tismer tismer at 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 ?
___
Roumen Petrov bugtrack at 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
Antoine Pitrou solipsis at pitrou.net writes:
Roumen Petrov bugtrack at 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
Antoine Pitrou wrote:
Antoine Pitrou solipsis at pitrou.net writes:
Roumen Petrov bugtrack at 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,
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 introduce a
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 the
Christian Tismer tismer at 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
Paul Moore wrote:
2009/7/22 Christian Tismer tis...@stackless.com:
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
On Thu, Jul 23, 2009 at 6:49 PM, Paul Moorep.f.mo...@gmail.com wrote:
2009/7/22 Christian Tismer tis...@stackless.com:
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
2009/7/23 David Cournapeau courn...@gmail.com:
On Thu, Jul 23, 2009 at 6:49 PM, Paul Moorep.f.mo...@gmail.com wrote:
2009/7/22 Christian Tismer tis...@stackless.com:
Maybe the simple solution is to prevent building extensions
with mingw, if the python executable was not also built with it?
On 7/23/09 2:04 AM, Antoine Pitrou wrote:
Christian Tismertismerat 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
Christian Tismer tismer at 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
Antoine Pitrou solipsis at 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
On 7/23/09 2:27 PM, Antoine Pitrou wrote:
Christian Tismertismerat 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
Christian Tismer tismer at 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
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 {
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_head
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:
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
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
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.
On Thu, Jul 23, 2009 at 4:40 AM, Antoine Pitrousolip...@pitrou.net 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,
On 7/22/09 5:17 PM, David Cournapeau wrote:
On Thu, Jul 23, 2009 at 4:40 AM, Antoine Pitrousolip...@pitrou.net 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
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,
37 matches
Mail list logo
