[PATCH v2 00/14] GLIBC LoongArch PATCHES

[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.

> 
> 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.