builtin_str{,n}cmp bug on s390{,x}

[Jakub Jelinek]

On Thu, Jul 10, 2003 at 07:39:00PM +0200, Ulrich Weigand wrote:
> Jakub Jelinek wrote:
> 
> >The problem is that s390 cmpstrsi insn
> >clc   0(17,%r1),0(%r2)
> >in the testcase below) does not behave like IA-32 rep; cmpsb.
> >The former has memcmp behaviour, the latter strcmp behaviour.
> 
> I was not aware that cmpstr was supposed to ensure that behaviour; 
> in fact even in the gcc 3.3 docs we read
> 
> "Block compare instruction, with five operands.  Operand 0 is the output;
> it has mode M.  The remaining four operands are like the operands
> of movstrM.  The two memory blocks specified are compared
> byte by byte in lexicographic order.  The effect of the instruction is
> to store a value in operand 0 whose sign indicates the result of the
> comparison."
> 
> which does appear to imply memcpy semantics ...
> 
> I see now that in the gcc-head docs, the sentence "The instruction is not 
> allowed to prefetch more than one byte at a time since either string may 
> end in the first byte and reading past that may access an invalid page or 
> segment and cause a fault." was added.  Does that mean that this is a
> new requirement that was added on the head only?

See PR optimization/10339.
Before that GCC was doing equally bad thing, but on all arches
(transforming strcmp/strncmp into memcmp).
IMNSHO that patch should be backported to gcc-3_3-branch (I have it on
gcc-3_3-rhl-branch for quite some time already), but unlike other arches
it will make zilch changes on s390*.

	Jakub