From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id 15BD73856DF9 for ; Fri, 15 Apr 2022 01:28:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 15BD73856DF9 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from [10.20.4.187] (unknown [10.20.4.187]) by mail.loongson.cn (Coremail) with SMTP id AQAAf9DxrxMlylhiSMkjAA--.44798S3; Fri, 15 Apr 2022 09:28:06 +0800 (CST) From: caiyinyu Subject: Re: [PATCH v2 00/14] GLIBC LoongArch PATCHES To: Adhemerval Zanella , libc-alpha@sourceware.org Cc: xuchenghua@loongson.cn References: <20211231064455.1030051-1-caiyinyu@loongson.cn> <65f49596-18eb-ef04-a89b-2f384f23e7d9@linaro.org> Message-ID: <44c39d29-6222-02a2-eb0a-e442e3151046@loongson.cn> Date: Fri, 15 Apr 2022 09:28:05 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <65f49596-18eb-ef04-a89b-2f384f23e7d9@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID: AQAAf9DxrxMlylhiSMkjAA--.44798S3 X-Coremail-Antispam: 1UD129KBjvJXoWxZw18tF4UXr1rZw48GryrXrb_yoW5Zrykpr n0gFWfCF4rtryktF4Ygr47tr4UtrWakw17JF95Xr1DAr1kK3Z8Xr12qrWkCa4xGrn8ury7 tasrWa4jkw15KaUanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvm14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26ryj6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4U JVWxJr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxV W8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xf McIj6xIIjxv20xvE14v26r126r1DMcIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7 v_Jr0_Gr1lF7xvr2IY64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7Mxk0xIA0c2IEe2xF o4CEbIxvr21lc2xSY4AK6svPMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r 4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF 67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2I x0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_JFI_Gr1lIxAIcVC2 z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnU UI43ZEXa7VUb4v3UUUUUU== X-CM-SenderInfo: 5fdl5xhq1xqz5rrqw2lrqou0/ X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00, KAM_ASCII_DIVIDERS, KAM_DMARC_STATUS, KAM_SHORT, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 15 Apr 2022 01:28:44 -0000 在 2022/1/4 下午9:27, Adhemerval Zanella 写道: > On 31/12/2021 03:44, caiyinyu wrote: >> FAIL: elf/ifuncmain1 >> FAIL: elf/ifuncmain1pic >> FAIL: elf/ifuncmain1pie >> FAIL: elf/ifuncmain1staticpic >> FAIL: elf/ifuncmain1staticpie >> FAIL: elf/ifuncmain1vis >> FAIL: elf/ifuncmain1vispic >> FAIL: elf/ifuncmain1vispie >> FAIL: elf/ifuncmain3 >> FAIL: elf/ifuncmain4 >> FAIL: elf/ifuncmain6pie >> FAIL: elf/ifuncmain7 >> FAIL: elf/ifuncmain7pic >> FAIL: elf/ifuncmain7pie >> FAIL: elf/tst-ifunc-fault-bindnow >> FAIL: elf/tst-ifunc-fault-lazy >> >> ifunc functions are not support yet > If the target does not support ifunc, why libc_cv_ld_gnu_indirect_function is being > set then? I think you will need to disable the usage of %gnu_indirect_function > on static linker. All ifunc problems are solved. >> c. >> FAIL: math/test-double-acos >> FAIL: math/test-double-asin >> FAIL: math/test-float32x-acos >> FAIL: math/test-float32x-asin >> FAIL: math/test-float64-acos >> FAIL: math/test-float64-asin >> >> These fails are caused by gcc optimizations. if we use -O0 options, these fails >> will pass. >> >> sysdeps/ieee754/dbl-64/e_asin.c: 343 >> =================================================================== >> 337 if (k>0x7ff00000 || (k == 0x7ff00000 && u.i[LOW_HALF] != 0)) return x + x; >> 0x00007ffff7f4daac <+1388>: lu12i.w $t0, 524032(0x7ff00) >> 0x00007ffff7f4dab0 <+1392>: blt $t0, $t2, 20(0x14) # 0x7ffff7f4dac4 <__ieee754_acos+1412> >> 0x00007ffff7f4dab4 <+1396>: bne $t2, $t0, 36(0x24) # 0x7ffff7f4dad8 <__ieee754_acos+1432> >> 0x00007ffff7f4dab8 <+1400>: ld.d $t0, $sp, 8(0x8) >> 0x00007ffff7f4dabc <+1404>: slli.w $t0, $t0, 0x0 >> 0x00007ffff7f4dac0 <+1408>: beqz $t0, 24(0x18) # 0x7ffff7f4dad8 <__ieee754_acos+1432> >> 0x00007ffff7f4dac4 <+1412>: fld.d $fa0, $sp, 8(0x8) >> 0x00007ffff7f4dac8 <+1416>: fadd.d $fa0, $fa0, $fa0 >> 0x00007ffff7f4dacc <+1420>: b -788(0xffffcec) # 0x7ffff7f4d7b8 <__ieee754_acos+632> >> >> 338 else { >> 339 u.i[HIGH_HALF]=0x7ff00000; >> 340 v.i[HIGH_HALF]=0x7ff00000; >> 341 u.i[LOW_HALF]=0; >> 342 v.i[LOW_HALF]=0; >> 343 return u.x/v.x; ///////// optimized out >> >> 0x00007ffff7f4dad8 <+1432>: pcaddu12i $t0, 63(0x3f) >> 0x00007ffff7f4dadc <+1436>: addi.d $t0, $t0, -1248(0xb20) >> 0x00007ffff7f4dae0 <+1440>: fld.d $fa0, $t0, 0 >> 0x00007ffff7f4dae4 <+1444>: b -812(0xffffcd4) # 0x7ffff7f4d7b8 <__ieee754_acos+632> >> >> 344 } >> 345 } >> 0x00007ffff7f4d7b8 <+632>: addi.d $sp, $sp, 16(0x10) >> 0x00007ffff7f4d7bc <+636>: jirl $zero, $ra, 0 >> 0x00007ffff7f4d7cc <+652>: addi.d $sp, $sp, 16(0x10) >> 0x00007ffff7f4d7d0 <+656>: jirl $zero, $ra, 0 >> 0x00007ffff7f4d8bc <+892>: addi.d $sp, $sp, 16(0x10) >> 0x00007ffff7f4d8c0 <+896>: jirl $zero, $ra, 0 >> =================================================================== > Is this being tracked by a GCC bug report? We need to understand if we > require to use math_force_eval to avoid such issue on other ports as > well. GCC upstream Fixed. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115