[glibc/vineet/upstream-work] ieee754/dbl-64: Reduce the scope of temporary storage varia

Vineet Gupta vgupta@sourceware.org
Fri Jun 5 20:55:08 GMT 2020


The branch 'vineet/upstream-work' was updated to point to:

 557e212d36... ieee754/dbl-64: Reduce the scope of temporary storage varia

It previously pointed to:

 ccf784eef0... ieee754/dbl-64: Reduce the scope of temporary storage varia

Diff:

!!! WARNING: THE FOLLOWING COMMITS ARE NO LONGER ACCESSIBLE (LOST):
-------------------------------------------------------------------

  ccf784e... ieee754/dbl-64: Reduce the scope of temporary storage varia

commit ccf784eef01f46322b9eab01e16178d8e896502b
Author: Vineet Gupta <vgupta@synopsys.com>
Date:   Fri Nov 8 11:32:00 2019 -0800

    ieee754/dbl-64: Reduce the scope of temporary storage variables
    
    This came to light when adding hard-flaot support to ARC glibc port
    without hardware sqrt support causing glibc build to fail:
    
    | ../sysdeps/ieee754/dbl-64/e_sqrt.c: In function '__ieee754_sqrt':
    | ../sysdeps/ieee754/dbl-64/e_sqrt.c:58:54: error: unused variable 'ty' [-Werror=unused-variable]
    |   double y, t, del, res, res1, hy, z, zz, p, hx, tx, ty, s;
    
    The reason being EMULV() macro uses the hardware provided
    __builtin_fma() variant, leaving temporary variables 'p, hx, tx, hy, ty'
    unused hence compiler warning and ensuing error.
    
    The intent of the patch was to fix that error, but EMULV is pervasive
    and used fair bit indirectly via othe rmacros, hence this patch.
    Functionally it should not result in code gen changes and if at all
    those would be better since the scope of those temporaries is greatly
    reduced now
    
    Built tested with aarch64-linux-gnu arm-linux-gnueabi arm-linux-gnueabihf hppa-linux-gnu x86_64-linux-gnu arm-linux-gnueabihf riscv64-linux-gnu-rv64imac-lp64 riscv64-linux-gnu-rv64imafdc-lp64 powerpc-linux-gnu microblaze-linux-gnu nios2-linux-gnu hppa-linux-gnu
    
    Also as suggested by Joseph [1] used --strip and compared the libs with
    and w/o patch and their sizes are exactly same (with gcc 9).
    
    |  624768 Jun  1 16:20 ./aarch64-linux-gnu/lib64/libm-2.31.9000.so
    |  382456 Jun  1 16:20 ./arm-linux-gnueabihf/lib/libm-2.31.9000.so
    |  611836 Jun  1 16:20 ./arm-linux-gnueabi/lib/libm-2.31.9000.so
    |  502556 Jun  1 16:19 ./hppa-linux-gnu/lib/libm-2.31.9000.so
    |  867608 Jun  1 16:19 ./microblaze-linux-gnu/lib/libm-2.31.9000.so
    |  724488 Jun  1 16:19 ./nios2-linux-gnu/lib/libm-2.31.9000.so
    |  788088 Jun  1 16:20 ./powerpc-linux-gnu/lib/libm-2.31.9000.so
    |  538944 Jun  1 16:20 ./riscv64-linux-gnu-rv64imafdc-lp64/lib64/lp64/libm-2.31.9000.so
    |  639272 Jun  1 16:20 ./riscv64-linux-gnu-rv64imac-lp64/lib64/lp64/libm-2.31.9000.so
    | 1321280 Jun  1 16:21 ./x86_64-linux-gnu/lib64/libm-2.31.9000.so
    
    [1] https://sourceware.org/pipermail/libc-alpha/2019-November/108267.html
    
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>


Summary of changes (added commits):
-----------------------------------

  557e212... ieee754/dbl-64: Reduce the scope of temporary storage varia

commit 557e212d36f01a643ac36d8ad437562ec63888fb
Author: Vineet Gupta <vgupta@synopsys.com>
Date:   Fri Nov 8 11:32:00 2019 -0800

    ieee754/dbl-64: Reduce the scope of temporary storage variables
    
    This came to light when adding hard-flaot support to ARC glibc port
    without hardware sqrt support causing glibc build to fail:
    
    | ../sysdeps/ieee754/dbl-64/e_sqrt.c: In function '__ieee754_sqrt':
    | ../sysdeps/ieee754/dbl-64/e_sqrt.c:58:54: error: unused variable 'ty' [-Werror=unused-variable]
    |   double y, t, del, res, res1, hy, z, zz, p, hx, tx, ty, s;
    
    The reason being EMULV() macro uses the hardware provided
    __builtin_fma() variant, leaving temporary variables 'p, hx, tx, hy, ty'
    unused hence compiler warning and ensuing error.
    
    The intent of the patch was to fix that error, but EMULV is pervasive
    and used fair bit indirectly via othe rmacros, hence this patch.
    Functionally it should not result in code gen changes and if at all
    those would be better since the scope of those temporaries is greatly
    reduced now
    
    Built tested with aarch64-linux-gnu arm-linux-gnueabi arm-linux-gnueabihf hppa-linux-gnu x86_64-linux-gnu arm-linux-gnueabihf riscv64-linux-gnu-rv64imac-lp64 riscv64-linux-gnu-rv64imafdc-lp64 powerpc-linux-gnu microblaze-linux-gnu nios2-linux-gnu hppa-linux-gnu
    
    Also as suggested by Joseph [1] used --strip and compared the libs with
    and w/o patch and they are bute-for-byte unchanged (with gcc 9).
    
    | for i in `find . -name libm-2.31.9000.so`;
    | do
    |    echo $i; diff $i /SCRATCH/vgupta/gnu2/install/glibcs/$i ; echo $?;
    | done
    
    | ./aarch64-linux-gnu/lib64/libm-2.31.9000.so
    | 0
    | ./arm-linux-gnueabi/lib/libm-2.31.9000.so
    | 0
    | ./x86_64-linux-gnu/lib64/libm-2.31.9000.so
    | 0
    | ./arm-linux-gnueabihf/lib/libm-2.31.9000.so
    | 0
    | ./riscv64-linux-gnu-rv64imac-lp64/lib64/lp64/libm-2.31.9000.so
    | 0
    | ./riscv64-linux-gnu-rv64imafdc-lp64/lib64/lp64/libm-2.31.9000.so
    | 0
    | ./powerpc-linux-gnu/lib/libm-2.31.9000.so
    | 0
    | ./microblaze-linux-gnu/lib/libm-2.31.9000.so
    | 0
    | ./nios2-linux-gnu/lib/libm-2.31.9000.so
    | 0
    | ./hppa-linux-gnu/lib/libm-2.31.9000.so
    | 0
    | ./s390x-linux-gnu/lib64/libm-2.31.9000.so
    
    [1] https://sourceware.org/pipermail/libc-alpha/2019-November/108267.html
    
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>


More information about the Glibc-cvs mailing list