From owner-freebsd-current@freebsd.org Sun Sep 16 17:50:40 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EDC610A6AEF; Sun, 16 Sep 2018 17:50:40 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailout.stack.nl (mailout05.stack.nl [IPv6:2001:610:1108:5010::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.stack.nl", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C6BA171C92; Sun, 16 Sep 2018 17:50:39 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from toad2.stack.nl (toad2.stack.nl [IPv6:2001:610:1108:5010::161]) by mailout.stack.nl (Postfix) with ESMTP id C27B44B; Sun, 16 Sep 2018 19:50:29 +0200 (CEST) Received: by toad2.stack.nl (Postfix, from userid 1677) id BB603892CD; Sun, 16 Sep 2018 19:50:29 +0200 (CEST) Date: Sun, 16 Sep 2018 19:50:29 +0200 From: Jilles Tjoelker To: Mark Millard Cc: freebsd-arm , FreeBSD Current Subject: Re: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context Message-ID: <20180916175029.GA55717@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2018 17:50:40 -0000 On Tue, Sep 11, 2018 at 08:48:03AM -0700, Mark Millard wrote: > [Adding listing broken tests, but ignoring sys/cddl/zfs/ ones. > lib/libc/string/memcmp_test:diff is one of them.] > ===> Broken tests > lib/libc/string/memcmp_test:diff -> broken: Premature exit; test case received signal 6 (core dumped) [3.962s] The problem here is that our definition of memcmp() is tighter than the one in the standards and glibc. We define the return value to be the difference between the first differing bytes, while the standards and glibc only define the sign (negative, zero or positive). Looking at contrib/cortex-strings/src/aarch64/memcmp.S, a bic pos, pos, #7 after the clz may help. On another note, the comment just below that, /* But we need to zero-extend (char is unsigned) the value and then perform a signed 32-bit subtraction. */ shows a wrong reason for doing the right thing since memcmp (as well as strcmp and strncmp) are defined to compare based on unsigned chars, regardless of the signedness of char. -- Jilles Tjoelker