From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by sourceware.org (Postfix) with ESMTPS id 0A1473858C56 for ; Tue, 21 Jun 2022 12:21:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0A1473858C56 Received: by mail-oi1-x229.google.com with SMTP id k24so16850319oij.2 for ; Tue, 21 Jun 2022 05:21:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ktssyBqSHxjVDoSIBWRxIdsoRTEL8EHQjJOrG7ljA3U=; b=oh0pYp9nSv3E3Dcwv3ukiMQPvY8xWHVmfXDaYeQfrfwRVRMZubLzZejnvZa1WKKBH7 T7Fvlhcs4DXGlvHlFfKrThdulbw0rDl18rVkD0qlLLi9Tx0BbgMuOCehcpvyPhjCYLKY FjwvgCG1KF0dDeNJbXIXMoShrx6ykYi+hOECu2WZl91yLhkGfQOMqoqj27nrhumFFnX2 aZgRvn3VAKihwsHFfOzFX8EGwjqnqBIaqj8E31/JMV9+8FNe/QeES1cpGQMeW/794jTw OsLgDzCHMtApkPnwdcMP8fn0lFwFE4V1STLgXSgb2QiKo/ZoZX/n/L/1lmNkW5kgl+4q FbvQ== X-Gm-Message-State: AOAM531vypTQraz1T8CwLfzTyCbuZsGhN+BUbXRp7oi+W4bfSRqPbUQ8 16vBXbGkYgoftlOHU1H8jh5ZqhFHBQd5jwhB X-Google-Smtp-Source: ABdhPJwIJceafs3oZmKPJo6G5iCy78KLhVV7Unru+fOuNUylekuRdckRiMdasafFlK5yH/faGgCO3w== X-Received: by 2002:a05:6808:300f:b0:2f9:81c1:7691 with SMTP id ay15-20020a056808300f00b002f981c17691mr18872741oib.208.1655814074211; Tue, 21 Jun 2022 05:21:14 -0700 (PDT) Received: from smtpclient.apple ([177.138.183.172]) by smtp.gmail.com with ESMTPSA id s204-20020aca45d5000000b0032f662af5d5sm9007237oia.1.2022.06.21.05.21.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jun 2022 05:21:13 -0700 (PDT) From: Adhemerval Zanella Message-Id: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: How to skip test when building glibc Date: Tue, 21 Jun 2022 09:21:04 -0300 In-Reply-To: Cc: Florian Weimer , Letu Ren via Libc-help To: Letu Ren References: <2323859E-CD57-4DB0-88EC-74901E407D35@linaro.org> <87o7yup1my.fsf@oldenburg.str.redhat.com> <4842386B-AB4B-4B08-BFEC-45B420868B55@linaro.org> <6FE8D53C-2116-49FD-B9EF-1328AEBEF16A@linaro.org> X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2022 12:21:17 -0000 > On 17 Jun 2022, at 05:12, Letu Ren wrote: >=20 >> Yes I think it worth to set a higher bond for tests that require a = lot of time, >> the issue is usually we tests with faster machines where defaults are = good >> enough. If you may please open bugs with the required time on the = platform >> you are testing, it would require to adjust on each test code to = increase the >> required timeout. >=20 > I think I should report bugs to glibc. The problem is where to know > the time limit for each failed unit test set by glibc and how to > measure the time consumed by tests. I think using bash time is not > precise. Is there something I can refer to? The default configuration for all testcases is to create a helper parent=20= process to handle timeout and spurious failures (such as segfault). You=20= can disable it by using the =E2=80=94direct command line with testrun.sh = (which=20 runs the test using the built glibc loader and libraries): builddir$ time ./testrun testcase =E2=80=94direct Some tests might require additional environment variables or arguments, easiest way to check is to get them is to copy from make check log. >=20 >> This might be a bug either in the compiler or in the environment you = are using. >> The commit log for riscv32 libm-test-ulps = (b2d175cdb755277ef5579fdac914768003bfbc5c) >> states that values does not match the RV32 on QEMU, so it might what = is >> happening. >>=20 >> If you are running on real hardware, it might be case where = floating-point >> in non default rounding mode has higher ULPs than expected (I am = assuming >> the RV64 ones were done in read hardware). You can >> regenerate the libm-test-ulps with `make regen-ulp`, this will show = some >> information on how to copy back the file on source tree. >>=20 >> We will need to increase the generic threshold what we consider an = error >> (as you can see any math function that shows ULPs larger than 8). >=20 > I use a HiFive Unmatched board to test. The hardware baseline is > RV64GC and the ABI is lp64d. I don't think I have the ability to solve > this problem currently. May need some time to learn how libm works. :( So you are indeed testing against the real hardware. Could you open a bug report [1] with the output of =E2=80=98make regen-ulps=E2=80=99 ? I = think we will need to update the minimum required ULPs. It can be also a regression on compiler that is generating larger error bounds, since the current ULP baseline seems also to be generated on read hardware. >=20 >> This is more worrisome because it means the NAN signal is not being >> propagated by some FP operation. I think you will need to debug to >> understand better that is happening, since strfromf code does a lot = of FP >> operations. >=20 > I don't think I have the ability to solve this problem currently. :( > Anyway, thanks for replying and analyzing the reason why unit tests > fail. I will try to investigate them. Could you also open another bug report with the output of the testcases? >=20 > Letu Ren [1] https://sourceware.org/bugzilla/