From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 2A4D73861030; Fri, 22 Jan 2021 18:21:59 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2A4D73861030
From: "kungfujesus06 at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug malloc/27227] Memory corruption for altivec unaligned load /
 store
Date: Fri, 22 Jan 2021 18:21:59 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: malloc
X-Bugzilla-Version: 2.32
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kungfujesus06 at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-27227-131-po8TMTFuPB@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-27227-131@http.sourceware.org/bugzilla/>
References: <bug-27227-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: glibc-bugs@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Glibc-bugs mailing list <glibc-bugs.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/glibc-bugs>,
 <mailto:glibc-bugs-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/glibc-bugs/>
List-Help: <mailto:glibc-bugs-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/glibc-bugs>,
 <mailto:glibc-bugs-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jan 2021 18:21:59 -0000

https://sourceware.org/bugzilla/show_bug.cgi?id=3D27227

--- Comment #2 from Adam Stylinski <kungfujesus06 at gmail dot com> ---
(In reply to Andreas Schwab from comment #1)
> There is not a single memory write in your example, thus any memory
> corruption must have happened somewhere else.  In any case, nothing here
> looks related to glibc.  Try valgrind.

Sorry, that was definitely not a complete example, I was simply showing the
access pattern.  The memory writes are occurring in similar loops, where the
unaligned writes happen the same way as the loads, but the writes are handl=
ed
exactly as they were in Apple's documentation:

void StoreUnaligned( vector unsigned char src, void *target )
{

    vector unsigned char MSQ, LSQ;
    vector unsigned char mask, align, zero, neg1;
    MSQ =3D vec_ld(0, target);

    // most significant quadword
    LSQ =3D vec_ld(16, target);
    // least significant quadword
    align =3D vec_lvsr(0, target);
    // create alignment vector
    zero =3D vec_spat_u8( 0 );
    // Create vector full of zeros
    neg1 =3D vec_splat_s8( -1 );
    // Create vector full of -1
    mask=3Dvec_perm(zero,neg1,align);
    Create select mask
    src=3Dvec_perm(src,src,align );

    // Right rotate stored data
    MSQ =3D vec_sel( MSQ, src, mask );
    // Insert data into MSQ part
    LSQ =3D vec_sel( src, LSQ, mask );
   // Insert data into LSQ part
   vec_st( MSQ, 0, target );
   // Store the MSQ part
   vec_st( LSQ, 16, target );
   // Store the LSQ part
}

I'm asking first if my access pattern for both loads and stores is faulty to
begin with, or if something changed in glibc recently for the POWER ABI with
regard to alignment.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=