On Wed, Sep 13, 2017 at 15:58:11 +0200, Joerg Sonnenberger wrote:
> On Wed, Sep 13, 2017 at 04:48:54PM +0300, Valery Ushakov wrote:
> > On a typical cpu that would be the alignment of "long double" I guess.
> > (I haven't checked, but it looks like that's what TINY_MIN_2POW
> > ensures for "tiny"
On Wed, Sep 13, 2017 at 04:48:54PM +0300, Valery Ushakov wrote:
> On a typical cpu that would be the alignment of "long double" I guess.
> (I haven't checked, but it looks like that's what TINY_MIN_2POW
> ensures for "tiny" allocation).
Vector registers require 128 or even 256bit alignment. We hav
On Wed, Sep 13, 2017 at 06:54:22 +0200, Martin Husemann wrote:
> On Wed, Sep 13, 2017 at 02:23:22AM +0300, Valery Ushakov wrote:
> > Long story short... That program overrides malloc and returns memory
> > that is only 8 bytes aligned. That creates problems for our pthreads,
> > as rwlock code a
On Wed, Sep 13, 2017 at 02:23:22AM +0300, Valery Ushakov wrote:
> Long story short... That program overrides malloc and returns memory
> that is only 8 bytes aligned. That creates problems for our pthreads,
> as rwlock code assumes that pthread_self() is 16-byte aligned and uses
> the lower bits
I just killed quite some time debugging a weird lockup I had with a
third party program under NetBSD.
Long story short... That program overrides malloc and returns memory
that is only 8 bytes aligned. That creates problems for our pthreads,
as rwlock code assumes that pthread_self() is 16-byte a
