[Bug libc/28572] New: Misaligned accesses in test-memcpy and test-mempcpy on hppa

[Bug libc/28572] New: Misaligned accesses in test-memcpy and test-mempcpy on hppa

[danglin at gcc dot gnu.org]

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

            Bug ID: 28572
           Summary: Misaligned accesses in test-memcpy and test-mempcpy on
                    hppa
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: danglin at gcc dot gnu.org
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

A recent change change has made memcpy incredibly slow on hppa.  There
are now millions of unaligned accesses in the memcpy tests:

handle_unaligned: 4310385 callbacks suppressed
ld.so.1(11442): unaligned access to 0x00000000f671cc15 at ip=0x0000000000011e53
ld.so.1(11442): unaligned access to 0x00000000f671cc19 at ip=0x0000000000011e53
ld.so.1(11442): unaligned access to 0x00000000f671cc1d at ip=0x0000000000011e53
ld.so.1(11442): unaligned access to 0x00000000f671cc21 at ip=0x0000000000011e53
ld.so.1(11442): unaligned access to 0x00000000f671cc25 at ip=0x0000000000011e53
handle_unaligned: 4391491 callbacks suppressed
ld.so.1(11442): unaligned access to 0x00000000f6b55c31 at ip=0x0000000000011ebf
ld.so.1(11442): unaligned access to 0x00000000f7316bf3 at ip=0x0000000000011ebb
ld.so.1(11442): unaligned access to 0x00000000f6b55c35 at ip=0x0000000000011ebf
ld.so.1(11442): unaligned access to 0x00000000f7316bf7 at ip=0x0000000000011ebb
ld.so.1(11442): unaligned access to 0x00000000f6b55c39 at ip=0x0000000000011ebf
handle_unaligned: 4280362 callbacks suppressed
ld.so.1(11442): unaligned access to 0x00000000f73d5f3f at ip=0x0000000000011ebb
ld.so.1(11442): unaligned access to 0x00000000f6c14f81 at ip=0x0000000000011ebf
ld.so.1(11442): unaligned access to 0x00000000f73d5f43 at ip=0x0000000000011ebb
ld.so.1(11442): unaligned access to 0x00000000f6c14f85 at ip=0x0000000000011ebf
ld.so.1(11442): unaligned access to 0x00000000f73d5f47 at ip=0x0000000000011ebb
...

I killed test-memcpy after 400 minutes.

Tests were probably okay on Nov. 1.

The generic memcpy from string/memcpy.c is used on hppa.

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[adhemerval.zanella at linaro dot org]

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

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
I think the recent change of test-memcpy.c
(d585ba47fcda99fdf228e3e45a01b11a15efbc5a) might have triggered an hidden bug
on generic implementation.  Could we get the input parameters that triggered
the first fault?

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2021-11-09 12:42 p.m., adhemerval.zanella at linaro dot org wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=28572
>
> Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |adhemerval.zanella at linaro dot o
>                     |                            |rg
>
> --- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
> I think the recent change of test-memcpy.c
> (d585ba47fcda99fdf228e3e45a01b11a15efbc5a) might have triggered an hidden bug
> on generic implementation.  Could we get the input parameters that triggered
> the first fault?
I suspect the unaligned accesses are in the test code:
ld.so.1(9795): unaligned access to 0x00000000f9a39001 at ip=0x0000000000011e33

(gdb) r
Starting program: /home/dave/gnu/glibc/objdir/elf/ld.so.1 --library-path 
/home/dave/gnu/glibc/objdir:/home/dave/gnu/glibc/objdir/math:/home/dave/gnu/glibc/objdir/elf:/home/dave/gnu/glibc/objdir/dlfcn:/home/dave/gnu/glibc/objdir/nss:/home/dave/gnu/glibc/objdir/nis:/home/dave/gnu/glibc/objdir/rt:/home/dave/gnu/glibc/objdir/resolv:/home/dave/gnu/glibc/objdir/mathvec:/home/dave/gnu/glibc/objdir/support:/home/dave/gnu/glibc/objdir/crypt:/home/dave/gnu/glibc/objdir/nptl 
/home/dave/gnu/glibc/objdir/string/test-memcpy
[Attaching after process 9792 fork to child process 9795]
[New inferior 2 (process 9795)]
[Detaching after fork from parent process 9792]
[Inferior 1 (process 9792) detached]
                         memcpy  builtin_memcpy  simple_memcpy

Thread 2.1 "ld.so.1" received signal SIGBUS, Bus error.
[Switching to process 9795]
0x00011e30 in ?? ()
(gdb) disass $pc-16,$pc+16
Dump of assembler code from 0x11e20 to 0x11e40:
    0x00011e20:  ldo 2d0(r15),r15
    0x00011e24:  ldi 0,ret0
    0x00011e28:  cmpb,= ret0,r11,0x11e40
    0x00011e2c:  shladd,l ret0,2,r10,r22
=> 0x00011e30:  stw ret0,0(r22)
    0x00011e34:  ldo 1(ret0),ret0
    0x00011e38:  cmpb,<> ret0,r11,0x11e30
    0x00011e3c:  shladd,l ret0,2,r10,r22
End of assembler dump.
(gdb) p/x $r22
$1 = 0xf9a39001
(gdb) p/x $ret0
$2 = 0x0
(gdb) p/x $r10
$3 = 0xf9a39001

This is in do_test1:
(gdb) break *0x00011e30
Breakpoint 1 at 0x11e30: file test-memcpy.c, line 253.
(gdb) list test-memcpy.c:253
248       size_t i;
249       size_t repeats;
250       for(repeats = 0; repeats < 2; repeats++)
251         {
252           for (i = 0; i < array_size; i++)
253             src[i] = (uint32_t) i;
254           FOR_EACH_IMPL (impl, 0)
255             {
256               memset (dest, -1, size);
257               CALL (impl, (char *) dest, (char *) src, size);

It looks like src is misaligned.

So far, I haven't been able to run test directly.  When I try to run it
directly, I get a divide by 0 trap in
__nptl_tls_static_size_for_stack():

/* Compute the size of the static TLS area based on data from the
    dynamic loader.  */
static inline size_t
__nptl_tls_static_size_for_stack (void)
{
   return roundup (GLRO (dl_tls_static_size), GLRO (dl_tls_static_align));
}

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin <danglin at gcc dot gnu.org> ---
Created attachment 13777
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13777&action=edit
Patch to fix unaligned access

Testing timeout for test-memcpy.  Revised test seems to take a long time.

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin <danglin at gcc dot gnu.org> ---
dave@mx3210:~/gnu/glibc/objdir$ time /home/dave/gnu/glibc/objdir/elf/ld.so.1
--library-path
/home/dave/gnu/glibc/objdir:/home/dave/gnu/glibc/objdir/math:/home/dave/gnu/glibc/objdir/elf:/home/dave/gnu/glibc/objdir/dlfcn:/home/dave/gnu/glibc/objdir/nss:/home/dave/gnu/glibc/objdir/nis:/home/dave/gnu/glibc/objdir/rt:/home/dave/gnu/glibc/objdir/resolv:/home/dave/gnu/glibc/objdir/mathvec:/home/dave/gnu/glibc/objdir/support:/home/dave/gnu/glibc/objdir/crypt:/home/dave/gnu/glibc/objdir/nptl
/home/dave/gnu/glibc/objdir/string/test-memcpy
                        memcpy  builtin_memcpy  simple_memcpy

real    13m19.839s
user    11m29.178s
sys     1m49.417s

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[danglin at gcc dot gnu.org]

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

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |goldstein.w.n at gmail dot com

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[goldstein.w.n at gmail dot com]

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

--- Comment #5 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
Hi,

So there are two commits that could be causing this:

commit 6c1e3c0fd09a9653f562db69e77281e358451163 (HEAD -> master)
Author: Noah Goldstein <goldstein.w.n@gmail.com>
Date:   Wed Nov 10 16:16:25 2021 -0600

    String: Split memcpy tests so that parallel build is faster

or

commit d585ba47fcda99fdf228e3e45a01b11a15efbc5a
Author: Noah Goldstein <goldstein.w.n@gmail.com>
Date:   Mon Nov 1 00:49:48 2021 -0500

    string: Make tests birdirectional test-memcpy.c


If its d585ba47fcda99fdf228e3e45a01b11a15efbc5a then the issue is simply with
the new tests.

I added them really just for x86_64 because the large memcpy case has some
complicated logic that was not previously tested.

Possibly for the large memcpy tests we could only iterate through
implementations returned by the ifunc and skip the generic/simple
implementations to speed things up?

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[dave.anglin at bell dot net]

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

--- Comment #6 from dave.anglin at bell dot net ---
On 2021-11-11 12:39 p.m., goldstein.w.n at gmail dot com wrote:
> commit d585ba47fcda99fdf228e3e45a01b11a15efbc5a
> Author: Noah Goldstein<goldstein.w.n@gmail.com>
> Date:   Mon Nov 1 00:49:48 2021 -0500
>
>      string: Make tests birdirectional test-memcpy.c
>
>
> If its d585ba47fcda99fdf228e3e45a01b11a15efbc5a then the issue is simply with
> the new tests.
It's the new tests that introduced the unaligned accesses.  That works okay on
x86 but not
on targets like PA-RISC that require strict alignment.  Even on x86, I believe
unaligned accesses
are slower than aligned ones.

There's a unaligned handler in PA-RISC Linux kernel but it's slow.
>
> I added them really just for x86_64 because the large memcpy case has some
> complicated logic that was not previously tested.
>
> Possibly for the large memcpy tests we could only iterate through
> implementations returned by the ifunc and skip the generic/simple
> implementations to speed things up?
Test passes on hppa with change change attached to bug but takes about 13
minutes.

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[goldstein.w.n at gmail dot com]

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

Noah Goldstein <goldstein.w.n at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[goldstein.w.n at gmail dot com]

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

--- Comment #7 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
(In reply to dave.anglin from comment #6)
> On 2021-11-11 12:39 p.m., goldstein.w.n at gmail dot com wrote:
> > commit d585ba47fcda99fdf228e3e45a01b11a15efbc5a
> > Author: Noah Goldstein<goldstein.w.n@gmail.com>
> > Date:   Mon Nov 1 00:49:48 2021 -0500
> >
> >      string: Make tests birdirectional test-memcpy.c
> >
> >
> > If its d585ba47fcda99fdf228e3e45a01b11a15efbc5a then the issue is simply with
> > the new tests.
> It's the new tests that introduced the unaligned accesses.  That works okay
> on x86 but not
> on targets like PA-RISC that require strict alignment.  Even on x86, I
> believe unaligned accesses
> are slower than aligned ones.
> 
> There's a unaligned handler in PA-RISC Linux kernel but it's slow.

Is there a way to make the test arch specific? Generally would prefer
keeping it in the `string/` directory so that its easier to run all the
tests but the tests are a real issue for non-x86.

I think we can move the large memcpy tests to sysdeps/x86_64 if 
there is no way to do arch specific tests in `string/`.

AFAIK x86_64 is the only implementation that has an extra-large case 
that requires additional tests.

H.J is there any reason that wouldn't work?


> >
> > I added them really just for x86_64 because the large memcpy case has some
> > complicated logic that was not previously tested.
> >
> > Possibly for the large memcpy tests we could only iterate through
> > implementations returned by the ifunc and skip the generic/simple
> > implementations to speed things up?
> Test passes on hppa with change change attached to bug but takes about 13
> minutes.

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> ---
memcpy should work on unaligned addresses.  Also we need to increase
TIMEOUT for memcpy.

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[goldstein.w.n at gmail dot com]

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

--- Comment #9 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
(In reply to H.J. Lu from comment #8)
> memcpy should work on unaligned addresses.  Also we need to increase
> TIMEOUT for memcpy.

It does "work" still. But if it takes 400+ minutes its not really a useful
test.

I think these tests are important for x86 but if the burden on other targets
is too high it doesn't seem reasonable to have them in `string/`

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Noah Goldstein from comment #9)
> (In reply to H.J. Lu from comment #8)
> > memcpy should work on unaligned addresses.  Also we need to increase
> > TIMEOUT for memcpy.
> 
> It does "work" still. But if it takes 400+ minutes its not really a useful
> test.
> 
> I think these tests are important for x86 but if the burden on other targets
> is too high it doesn't seem reasonable to have them in `string/`

Are they for performance or correctness?

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[goldstein.w.n at gmail dot com]

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

--- Comment #11 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
(In reply to H.J. Lu from comment #10)
> (In reply to Noah Goldstein from comment #9)
> > (In reply to H.J. Lu from comment #8)
> > > memcpy should work on unaligned addresses.  Also we need to increase
> > > TIMEOUT for memcpy.
> > 
> > It does "work" still. But if it takes 400+ minutes its not really a useful
> > test.
> > 
> > I think these tests are important for x86 but if the burden on other targets
> > is too high it doesn't seem reasonable to have them in `string/`
> 
> Are they for performance or correctness?

Correctness.

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[adhemerval.zanella at linaro dot org]

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

--- Comment #12 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
The misaligned access come from string/test-memcpy-support.h, which uses the
input alignment to create 'uint32_t*' pointers.  This is the issue we should
fix for this bug report, but I don't think the patch proposed is the best
approach. I think the following should work, but I did not tested on machine
that does not support unaligned access:

diff --git a/string/test-memcpy-support.h b/string/test-memcpy-support.h
index 419158a420..69c983957f 100644
--- a/string/test-memcpy-support.h
+++ b/string/test-memcpy-support.h
@@ -141,7 +141,7 @@ do_test1 (size_t align1, size_t align2, size_t size)
   for (repeats = 0; repeats < 2; repeats++)
     {
       for (i = 0; i < array_size; i++)
-        src[i] = (uint32_t)i;
+        memcpy (&src[i], & (uint32_t){i}, sizeof (uint32_t));
       FOR_EACH_IMPL (impl, 0)
       {
         memset (dest, -1, size);
@@ -149,7 +149,7 @@ do_test1 (size_t align1, size_t align2, size_t size)
         if (memcmp (src, dest, size))
           {
             for (i = 0; i < array_size; i++)
-              if (dest[i] != src[i])
+             if (memcmp (&dest[i], &src[i], sizeof (uint32_t)) != 0)
                 {
                   error (0, 0,
                          "Wrong result in function %s dst \"%p\" src \"%p\" "


For the test-memcpy taking too much time, I think we should track it on another
bug.

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[dave.anglin at bell dot net]

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

--- Comment #13 from dave.anglin at bell dot net ---
On 2021-11-11 2:52 p.m., goldstein.w.n at gmail dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=28572
>
> --- Comment #9 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
> (In reply to H.J. Lu from comment #8)
>> memcpy should work on unaligned addresses.  Also we need to increase
>> TIMEOUT for memcpy.
> It does "work" still. But if it takes 400+ minutes its not really a useful
> test.
That only happens when the unaligned accesses fault.  What's wrong with marking
the src
and dst types as unaligned pointers (i.e., alignment of 1)?

It's easy to modify the typedef in the patch to only use alignment 1 on hppa
and other strict
alignment architectures.
>
> I think these tests are important for x86 but if the burden on other targets
> is too high it doesn't seem reasonable to have them in `string/`
I agree.  HJL already bumped timeout.  How much impact does patch have on x86?

commit a6a9c1a36b48f304c8a2138c147d88a448161366
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Sun Nov 7 06:41:16 2021 -0800

     test-memcpy.c: Double TIMEOUT to (8 * 60)

     commit d585ba47fcda99fdf228e3e45a01b11a15efbc5a
     Author: Noah Goldstein <goldstein.w.n@gmail.com>
     Date:   Mon Nov 1 00:49:48 2021 -0500

         string: Make tests birdirectional test-memcpy.c

         This commit updates the memcpy tests to test both dst > src and dst <
         src. This is because there is logic in the code based on the

         Signed-off-by: Noah Goldstein <goldstein.w.n@gmail.com>
         Reviewed-by: H.J. Lu <hjl.tools@gmail.com>

     significantly increased the number of tests.  On Intel Core i7-1165G7,
     test-memcpy takes 120 seconds to run when machine is idle. Double
     TIMEOUT to (8 * 60) for test-memcpy to avoid timeout when machine is
     under heavy load.

Dave

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[dave.anglin at bell dot net]

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

--- Comment #14 from dave.anglin at bell dot net ---
On 2021-11-11 3:05 p.m., adhemerval.zanella at linaro dot org wrote:
> -        src[i] = (uint32_t)i;
> +        memcpy (&src[i], & (uint32_t){i}, sizeof (uint32_t));
I will test to see if this works correctly when src is misaligned.

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[goldstein.w.n at gmail dot com]

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

--- Comment #15 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
(In reply to dave.anglin from comment #14)
> On 2021-11-11 3:05 p.m., adhemerval.zanella at linaro dot org wrote:
> > -        src[i] = (uint32_t)i;
> > +        memcpy (&src[i], & (uint32_t){i}, sizeof (uint32_t));
> I will test to see if this works correctly when src is misaligned.

If it doesn't we could always throw out the `uint32_t` initializing
and initialize with `src`/`dst` as `char *` like in `do_test (void)`.

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[goldstein.w.n at gmail dot com]

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

--- Comment #16 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
(In reply to Adhemerval Zanella from comment #12)
> The misaligned access come from string/test-memcpy-support.h, which uses the
> input alignment to create 'uint32_t*' pointers.  This is the issue we should
> fix for this bug report, but I don't think the patch proposed is the best
> approach. I think the following should work, but I did not tested on machine
> that does not support unaligned access:
> 
> diff --git a/string/test-memcpy-support.h b/string/test-memcpy-support.h
> index 419158a420..69c983957f 100644
> --- a/string/test-memcpy-support.h
> +++ b/string/test-memcpy-support.h
> @@ -141,7 +141,7 @@ do_test1 (size_t align1, size_t align2, size_t size)
>    for (repeats = 0; repeats < 2; repeats++)
>      {
>        for (i = 0; i < array_size; i++)
> -        src[i] = (uint32_t)i;
> +        memcpy (&src[i], & (uint32_t){i}, sizeof (uint32_t));
>        FOR_EACH_IMPL (impl, 0)
>        {
>          memset (dest, -1, size);
> @@ -149,7 +149,7 @@ do_test1 (size_t align1, size_t align2, size_t size)
>          if (memcmp (src, dest, size))
>            {
>              for (i = 0; i < array_size; i++)
> -              if (dest[i] != src[i])
> +             if (memcmp (&dest[i], &src[i], sizeof (uint32_t)) != 0)
>                  {
>                    error (0, 0,
>                           "Wrong result in function %s dst \"%p\" src \"%p\"
> "
> 
> 
> For the test-memcpy taking too much time, I think we should track it on
> another bug.

Fair enough. I had misread the bug-report and thought it was
about execution time in general.

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[danglin at gcc dot gnu.org]

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

--- Comment #17 from John David Anglin <danglin at gcc dot gnu.org> ---
(In reply to Adhemerval Zanella from comment #12)
> The misaligned access come from string/test-memcpy-support.h, which uses the
> input alignment to create 'uint32_t*' pointers.  This is the issue we should
> fix for this bug report, but I don't think the patch proposed is the best
> approach. I think the following should work, but I did not tested on machine
> that does not support unaligned access:
> 
> diff --git a/string/test-memcpy-support.h b/string/test-memcpy-support.h
> index 419158a420..69c983957f 100644
> --- a/string/test-memcpy-support.h
> +++ b/string/test-memcpy-support.h
> @@ -141,7 +141,7 @@ do_test1 (size_t align1, size_t align2, size_t size)
>    for (repeats = 0; repeats < 2; repeats++)
>      {
>        for (i = 0; i < array_size; i++)
> -        src[i] = (uint32_t)i;
> +        memcpy (&src[i], & (uint32_t){i}, sizeof (uint32_t));
>        FOR_EACH_IMPL (impl, 0)
>        {
>          memset (dest, -1, size);
> @@ -149,7 +149,7 @@ do_test1 (size_t align1, size_t align2, size_t size)
>          if (memcmp (src, dest, size))
>            {
>              for (i = 0; i < array_size; i++)
> -              if (dest[i] != src[i])
> +             if (memcmp (&dest[i], &src[i], sizeof (uint32_t)) != 0)
>                  {
>                    error (0, 0,
>                           "Wrong result in function %s dst \"%p\" src \"%p\"
> "
> 
> 
> For the test-memcpy taking too much time, I think we should track it on
> another bug.

This works for me.  It's slightly slower:

                        memcpy  builtin_memcpy  simple_memcpy

real    13m48.299s
user    12m0.113s
sys     1m47.267s

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[goldstein.w.n at gmail dot com]

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

--- Comment #18 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
Fixed with:
https://sourceware.org/git/?p=glibc.git;a=commit;h=409a73581687914ac0555f6a468469578f97e70f

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[dave.anglin at bell dot net]

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

--- Comment #19 from dave.anglin at bell dot net ---
On 2021-12-07 11:21 p.m., goldstein.w.n at gmail dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=28572
>
> --- Comment #18 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
> Fixed with:
> https://sourceware.org/git/?p=glibc.git;a=commit;h=409a73581687914ac0555f6a468469578f97e70f
Thanks Noah.

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

[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |2.35
            Version|unspecified                 |2.35
         Resolution|---                         |FIXED

--- Comment #20 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed.

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