From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa5.hgst.iphmx.com (esa5.hgst.iphmx.com [216.71.153.144]) by sourceware.org (Postfix) with ESMTPS id 8BD7B386EC4F for ; Mon, 24 Aug 2020 18:17:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8BD7B386EC4F IronPort-SDR: Ld3ZPsCST8yl8ps9FiscbFxsGmOyF4ajWEx4T5Pf+5+mf/pQBQ+vIiOTsnri5G3zdFbvT6tJDA Zik2AedZLYJCIByLF/5x2Gr1Me/VDIj6Xa1GzEA/2jmp0dWj0Qwq2QLz3yXm88lPv21PSiUGDf d1Kj5jYXIcp8Icgs0PxjgYl9BLM4LuCt23AI2DEbpiTt4CLHXx8VqDYyg0ZtCgAnG1MgJ8gT/n iGuKxAdzkbu13olJSMYdc8/vgjhzRvGU3MOqFYan7tOcKtgHu6AhDf8Y4IBIZepAagc2sS5bt4 bXw= X-IronPort-AV: E=Sophos;i="5.76,349,1592841600"; d="scan'208";a="145714847" Received: from uls-op-cesaip02.wdc.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 25 Aug 2020 02:17:26 +0800 IronPort-SDR: NCB3KHwTV585VpwzsEUskq0xxo8NjXVvPq/dfjSo+jRkrtm8aIcGURHTUEIK+4/QUrChCC4JzA 4Mxp0+VT598w== Received: from uls-op-cesaip01.wdc.com ([10.248.3.36]) by uls-op-cesaep02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Aug 2020 11:04:14 -0700 IronPort-SDR: y78WbWZmpFx1tDCvyUTIYx41N/Ky9PIX2+5DBVu3I07Sql0sm0aRbvLeYr6iJV2LT1bu/kWhI5 EdtF1oYzThOw== WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Aug 2020 11:17:24 -0700 Date: Mon, 24 Aug 2020 19:17:19 +0100 (BST) From: "Maciej W. Rozycki" To: Alistair Francis cc: Nelson Chu , Alistair Francis , GNU C Library Subject: Re: [PATCH v5 00/17] glibc port for 32-bit RISC-V (RV32) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 18:17:28 -0000 On Mon, 24 Aug 2020, Alistair Francis wrote: > > Would you be able to see if there is any interesting information in the > > respective .out files and/or the overall test log? > > Yep, see below for the RV32 failure logs: > > elf/tst-libc_dlvsym.out > error: tst-libc_dlvsym.h:103: symbol _sys_errlist not found at any version > error: 1 test failures > > elf/tst-libc_dlvsym-static.out > error: tst-libc_dlvsym.h:103: symbol _sys_errlist not found at any version Well, we have this in NEWS: * The deprecated symbols sys_errlist, _sys_errlist, sys_nerr, and _sys_nerr are no longer available to newly linked binaries, and their declarations have been removed from from . They are exported solely as compatibility symbols to support old binaries. All programs should use strerror or strerror_r instead. so it looks like a test case bug to me; the symbol is expected not to be there given that we have no compatibility with previous library versions to take care of. Not a showstopper for RV32 inclusion IMO. > io/tst-lockf.out > error: subprocess failed: lockf > error: unexpected output from subprocess > tst-lockf.c:49: numeric comparison failure > left: 0 (0x0); from: lockf (temp_fd, F_TEST, 1024) > right: -1 (0xffffffff); from: -1 > error: 2 test failures This might be more interesting to look into further; as `len' is of the `off_t' type it would be good to double-check it is correctly handled. > stdlib/tst-strfrom.out > Testing in locale: C > strfromf: got NAN (3), expected -NAN (4) > strfromf32: got NAN (3), expected -NAN (4) > Testing in locale: en_US.ISO-8859-1 > strfromf: got NAN (3), expected -NAN (4) > strfromf32: got NAN (3), expected -NAN (4) > Testing in locale: en_US.UTF-8 > strfromf: got NAN (3), expected -NAN (4) > strfromf32: got NAN (3), expected -NAN (4) > > stdlib/tst-strfrom-locale.out > Testing in locale: de_DE.UTF-8 > strfromf: got NAN (3), expected -NAN (4) > strfromf32: got NAN (3), expected -NAN (4) > Testing in locale: tr_TR.ISO-8859-9 > strfromf: got NAN (3), expected -NAN (4) > strfromf32: got NAN (3), expected -NAN (4) > Testing in locale: tr_TR.UTF-8 > strfromf: got NAN (3), expected -NAN (4) > strfromf32: got NAN (3), expected -NAN (4) > > I'm assuming that stdlib/tst-strfrom and stdlib/tst-strfrom-locale are > just related to QEMU FP bugs, as they fail for both RV32 and RV64. Agreed, and in any case RV32 does not perform any worse than RV64. Of course it would be good to look into it anyway, but it shouldn't be a showstopper for RV32 inclusion IMO. > > > NOTE: This doesn't include the failing maths tests (that is an issue > > > only when running on QEMU) or the PLT issue for RISC-V 32-bit. > > > > Ack. Can you check if the PLT issue has been fixed with > > ? > > Yes, using the latest binutils with those patches applied seems to fix > the PLT failures. Good to know, thanks for confirming. So I guess we can ignore the PLT check failure and expect anyone caring about clean results to use most up to date binutils once the fix has been included (and until then use the patch applied locally). I've cc-ed Nelson to give him some incentive to upstream his fix quickly. Maciej