Message ID | 20211231064455.1030051-1-caiyinyu@loongson.cn |
---|---|
Headers | show |
Series | GLIBC LoongArch PATCHES | expand |
On Fri, 31 Dec 2021, caiyinyu wrote: > b. > 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 IFUNC isn't supported, the configure test (libc_cv_ld_gnu_indirect_function) should fail, have-ifunc should be no and elf/Makefile should disable the tests. Those failures suggest you have partial support in the toolchain - enough binutils support for the tests to be enabled - but are either missing glibc support, or some of the toolchain support is broken. In that case, you should fix/add the broken/missing support so that the tests pass. (Or if it's wrong that the libc_cv_ld_gnu_indirect_function test passes at all, maybe that's a binutils bug and you need to fix the binutils port so that that configure test fails.) > 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. So that issue needs fixing in GCC upstream. > 10. Note the need for a manual/math.texi update in the list of > configurations supporting _Float128. > > not support yet It's supported by the port (with the same ABI as long double, via the ieee754/ldbl-128 inclusion in sysdeps/loongarch/Implies) - the functions are in the ABI test baselines. So you need to update math.texi to reflect that. > 13. arch_minimum_kernel should be set to 10.0.0 until the actual upstream > kernel version that gets the port is known, and then to the actual > upstream version (so 5.14.0 or later). Accordingly, kernel-features.h > should not have any "before 4.20" conditionals in it (so you don't need an > architecture-specific kernel-features.h at all). > > corrected You have arch_minimum_kernel=5.15.0, but the support isn't in 5.15.0, and indeed isn't in Linus's git tree for 5.16 either. Once it's in Linus's git tree, you can set arch_minimum_kernel to the actual version that will have the port. Until then, you should use 10.0.0 as a placeholder.
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. > > 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.
在 2022/1/1 上午1:34, Joseph Myers 写道: > On Fri, 31 Dec 2021, caiyinyu wrote: > >> b. >> 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 IFUNC isn't supported, the configure test > (libc_cv_ld_gnu_indirect_function) should fail, have-ifunc should be no > and elf/Makefile should disable the tests. > > Those failures suggest you have partial support in the toolchain - enough > binutils support for the tests to be enabled - but are either missing > glibc support, or some of the toolchain support is broken. In that case, > you should fix/add the broken/missing support so that the tests pass. (Or > if it's wrong that the libc_cv_ld_gnu_indirect_function test passes at > all, maybe that's a binutils bug and you need to fix the binutils port so > that that configure test fails.) All ifunc problems are fixed. >> 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. > So that issue needs fixing in GCC upstream. GCC fixed. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115 >> 10. Note the need for a manual/math.texi update in the list of >> configurations supporting _Float128. >> >> not support yet > It's supported by the port (with the same ABI as long double, via the > ieee754/ldbl-128 inclusion in sysdeps/loongarch/Implies) - the functions > are in the ABI test baselines. So you need to update math.texi to reflect > that. Fixed. >> 13. arch_minimum_kernel should be set to 10.0.0 until the actual upstream >> kernel version that gets the port is known, and then to the actual >> upstream version (so 5.14.0 or later). Accordingly, kernel-features.h >> should not have any "before 4.20" conditionals in it (so you don't need an >> architecture-specific kernel-features.h at all). >> >> corrected > You have arch_minimum_kernel=5.15.0, but the support isn't in 5.15.0, and > indeed isn't in Linus's git tree for 5.16 either. > > Once it's in Linus's git tree, you can set arch_minimum_kernel to the > actual version that will have the port. Until then, you should use 10.0.0 > as a placeholder. Fixed.
在 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