From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) by sourceware.org (Postfix) with ESMTPS id 1F1BA3858296 for ; Thu, 16 Jun 2022 17:43:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1F1BA3858296 Received: by mail-pg1-x532.google.com with SMTP id r5so1885303pgr.3 for ; Thu, 16 Jun 2022 10:43:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EBRfY+Almc+t//R4tn0YlrSAJxjHthQkMKLMqbSEO4k=; b=YLeHXVT+23qIvMvDr1xlyYWb292c3ungWt05bqYSuBcf4bFxGyFTUPuaDkJfv2zdlw YX7X2/pfuyJoVPzh8jgHr5wBaCtyF9E/XmJdZ5B4y+jphHq3/1mcRHC2BNt/42ZH+gWT Or6/8ylerMCloX4IVmbGSJRbOsfGo5z8qcRXBByY2g4UZBw7KgAdYdJDwf1VeGaTgA0t e0V9Mcr/jkWQhxVMIoenG/wAk2nzLRlae4qoSKe2Gn14IanEG286SadqY6Da4v4+a5oA RvZV05rR6QI3UtJaujKjbXEgjp8QIy1bMMK4U5KpkBF0knwHX3RnWFq8XPPDP/Ae4YXM YeCw== X-Gm-Message-State: AJIora8jD9bJ3C846YNR8/MTo3Hco+XFPXH3Hz4ZxD5nvd3BpMekVADz 72DVE3DJ24RqtqRJ6w+7kNUsPQ== X-Google-Smtp-Source: AGRyM1t6fuUZN/Dx1vkKm08D6Jzk79dqKbNm0yhdFa/Ks9e2m9I5SKoW1IMvE86KNeruIat9pDIfHQ== X-Received: by 2002:aa7:8111:0:b0:520:90b0:de52 with SMTP id b17-20020aa78111000000b0052090b0de52mr5728318pfi.7.1655401397047; Thu, 16 Jun 2022 10:43:17 -0700 (PDT) Received: from smtpclient.apple ([192.77.111.2]) by smtp.gmail.com with ESMTPSA id im16-20020a170902bb1000b00163e5f99ee9sm1922197plb.166.2022.06.16.10.43.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jun 2022 10:43:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: How to skip test when building glibc From: Adhemerval Zanella In-Reply-To: Date: Thu, 16 Jun 2022 10:43:14 -0700 Cc: Florian Weimer , Letu Ren via Libc-help Content-Transfer-Encoding: quoted-printable Message-Id: <6FE8D53C-2116-49FD-B9EF-1328AEBEF16A@linaro.org> References: <2323859E-CD57-4DB0-88EC-74901E407D35@linaro.org> <87o7yup1my.fsf@oldenburg.str.redhat.com> <4842386B-AB4B-4B08-BFEC-45B420868B55@linaro.org> To: Letu Ren X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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: Thu, 16 Jun 2022 17:43:20 -0000 > On 15 Jun 2022, at 22:13, Letu Ren wrote: >=20 > On Thu, Jun 16, 2022 at 4:33 AM Adhemerval Zanella > wrote: >>=20 >> I think ideally we should either split the tests that are taking too = much time >> or increase the minimum expected timeout (so TIMEOUT_FACTOR is not >> really needed as a default option). >=20 > Yes, I totally agree with you. I think I should only increase the > timeout limit to those tests which are necessary. Setting > TIMEOUTFACTOR of all tests to 300 is not a good idea. However I don't > know how to do that. I haven't figured out where the timeout limit is > set after looking through code and doc. Should I report those failures > to glibc bug mailing list, because some of them aren't mentioned in > release notes? 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=20 you are testing, it would require to adjust on each test code to = increase the required timeout. >=20 >> For the tests that haven=E2=80=99t failed due a TIMEOUT, which are = the *.out contents? >=20 > stdlib/test-bz22786 is another failure due to a timeout issue, It's > just my carelessness. So we have four failures left. Their *.out > contents are listed below. >=20 > # cat math/test-float-j0.out > testing float (without inline functions) > Failure: Test: j0_upward (0x2.67a2a4p+0) > Result: > is: 5.64343701e-08 0x1.e4c47ep-25 > should be: 5.64344021e-08 0x1.e4c490p-25 > difference: 3.19744232e-14 0x1.200000p-45 > ulp : 9.0000 > max.ulp : 8.0000 > Maximal error of `j0_upward' > is : 9 ulp > accepted: 8 ulp >=20 > Test suite completed: > 348 test cases plus 344 tests for exception flags and > 344 tests for errno executed. > 2 errors occurred. >=20 > # cat math/test-float32-j0.out > testing _Float32 (without inline functions) > Failure: Test: j0_upward (0x2.67a2a4p+0) > Result: > is: 5.64343701e-08 0x1.e4c47ep-25 > should be: 5.64344021e-08 0x1.e4c490p-25 > difference: 3.19744232e-14 0x1.200000p-45 > ulp : 9.0000 > max.ulp : 8.0000 > Maximal error of `j0_upward' > is : 9 ulp > accepted: 8 ulp >=20 > Test suite completed: > 348 test cases plus 344 tests for exception flags and > 344 tests for errno executed. > 2 errors occurred. 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)=20 states that values does not match the RV32 on QEMU, so it might what is happening. 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. 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 >=20 > # cat 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) >=20 > # cat 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) 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=20 understand better that is happening, since strfromf code does a lot of = FP=20 operations.