[SPARC] supporting more than 2g in niagara4 memcpy and memset

  Hi.

The niagara4-specific versions of memcpy and memset do signed 32bit
compares with the size of the buffer to copy/set.  Anything larger than
2G will have the 32st bit set and will be treated as negative.

The problem is easy to reproduce in a T4, T5 or T7 machine:

p1 = (char*) mmap (NULL, 0xe0000000,
                   PROT_READ | PROT_WRITE, MAP_PRIVATE |
                   MAP_ANONYMOUS, -1, 0);
p2 = (char*) mmap (NULL, 0xe0000000,
                   PROT_READ | PROT_WRITE, MAP_PRIVATE |
                   MAP_ANONYMOUS, -1, 0);
memset (p1, 0xc, 0xe0000000);      /* Only 3 bytes are set.  */
dst = memcpy (p2, p1, 0xe0000000); /* Only 3 bytes are copied.  */

The patch below fixes the issue by using the XCC condition codes in the
proper branch instructions.

Tested in sparc64-unknown-linux-gnu.
No regressions observed.

Thanks.

2014-11-11  Jose E. Marchesi  <jose.marchesi@oracle.com>

	* sysdeps/sparc/sparc64/multiarch/memcpy-niagara4.S: Use the XCC
	condition codes when comparing buffer sizes.
	* sysdeps/sparc/sparc64/multiarch/memset-niagara4.S: Likewise.
  

From: jose.marchesi@oracle.com (Jose E. Marchesi)
Date: Tue, 11 Nov 2014 15:09:13 +0100

> Tested in sparc64-unknown-linux-gnu.
> No regressions observed.

Can I please convince you guys to test 32-bit stuff more strongly than
64-bit?  Please?

Both targets are important, but 32-bit sparcv9 multiarch is used more
than 64-bit is.

Becuase you didn't tag the sparc32/sparcv9/multiarch/foo-niagara4.S
files with the proper defines, 32-bit sparcv9 multiarch builds will
use %xcc and BPR too, which we absolutely do not want.

In the future if I don't see it mentioned that you tested 32-bit
targets, I'm going to ask you to resubmit after you have doen so.

I've made the same polite request with your sparc binutils submissions
so it is very disappointing to see you fall into the same bad habit
with your GLIBC work.

Thanks.
  

Hi David.
    
    Becuase you didn't tag the sparc32/sparcv9/multiarch/foo-niagara4.S
    files with the proper defines, 32-bit sparcv9 multiarch builds will
    use %xcc and BPR too, which we absolutely do not want.

Oops, I missed that.
    
    In the future if I don't see it mentioned that you tested 32-bit
    targets, I'm going to ask you to resubmit after you have doen so.
    
    I've made the same polite request with your sparc binutils submissions
    so it is very disappointing to see you fall into the same bad habit
    with your GLIBC work.

Since I got your request I am testing everything in sparc-*-linux-*
targets as well as sparc64-*-linux-*... but for this patch, which was
written long ago.  Sorry about that :(
  

David, could you say if this fix is ok?

On Wed, Nov 12, 2014 at 08:52:35AM +0100, Jose E. Marchesi wrote:
> 
> Hi David.
>     
>     Becuase you didn't tag the sparc32/sparcv9/multiarch/foo-niagara4.S
>     files with the proper defines, 32-bit sparcv9 multiarch builds will
>     use %xcc and BPR too, which we absolutely do not want.
> 
> Oops, I missed that.
>     
>     In the future if I don't see it mentioned that you tested 32-bit
>     targets, I'm going to ask you to resubmit after you have doen so.
>     
>     I've made the same polite request with your sparc binutils submissions
>     so it is very disappointing to see you fall into the same bad habit
>     with your GLIBC work.
> 
> Since I got your request I am testing everything in sparc-*-linux-*
> targets as well as sparc64-*-linux-*... but for this patch, which was
> written long ago.  Sorry about that :(
  

From: Ondřej Bílka <neleai@seznam.cz>
Date: Thu, 27 Nov 2014 17:47:10 +0100

> David, could you say if this fix is ok?

It's not ok, it needs to either remove the conditional XCC
stuff, or define something appropriate in the sparcv9 32-bit
case.