Skip to content
Snippets Groups Projects
  • Joseph Myers's avatar
    d758aeb5
    Correct libgcc complex multiply excess precision handling (PR libgcc/77519). · d758aeb5
    Joseph Myers authored
    libgcc complex multiply is meant to eliminate excess
    precision from certain internal values by forcing them to memory in
    exactly those cases where the type has excess precision.  But in
    https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01894.html I
    accidentally inverted the logic so that values get forced to memory in
    exactly the cases where it's not needed.  (This is a pessimization in
    the no-excess-precision case, in principle could lead to bad results
    depending on code generation in the excess-precision case.  Note: I do
    not have a test demonstrating bad results.)
    
    Bootstrapped with no regressions on x86_64-pc-linux-gnu.  Code size
    went down on x86_64 as expected; old sizes:
    
       text    data     bss     dec     hex filename
        887       0       0     887     377 _muldc3.o
        810       0       0     810     32a _mulsc3.o
       2032       0       0    2032     7f0 _multc3.o
        983       0       0     983     3d7 _mulxc3.o
    
    New sizes:
    
        847       0       0     847     34f _muldc3.o
        770       0       0     770     302 _mulsc3.o
       2032       0       0    2032     7f0 _multc3.o
        951       0       0     951     3b7 _mulxc3.o
    
    	PR libgcc/77519
    	* libgcc2.c (NOTRUNC): Invert settings.
    
    From-SVN: r240033
    d758aeb5
    History
    Correct libgcc complex multiply excess precision handling (PR libgcc/77519).
    Joseph Myers authored
    libgcc complex multiply is meant to eliminate excess
    precision from certain internal values by forcing them to memory in
    exactly those cases where the type has excess precision.  But in
    https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01894.html I
    accidentally inverted the logic so that values get forced to memory in
    exactly the cases where it's not needed.  (This is a pessimization in
    the no-excess-precision case, in principle could lead to bad results
    depending on code generation in the excess-precision case.  Note: I do
    not have a test demonstrating bad results.)
    
    Bootstrapped with no regressions on x86_64-pc-linux-gnu.  Code size
    went down on x86_64 as expected; old sizes:
    
       text    data     bss     dec     hex filename
        887       0       0     887     377 _muldc3.o
        810       0       0     810     32a _mulsc3.o
       2032       0       0    2032     7f0 _multc3.o
        983       0       0     983     3d7 _mulxc3.o
    
    New sizes:
    
        847       0       0     847     34f _muldc3.o
        770       0       0     770     302 _mulsc3.o
       2032       0       0    2032     7f0 _multc3.o
        951       0       0     951     3b7 _mulxc3.o
    
    	PR libgcc/77519
    	* libgcc2.c (NOTRUNC): Invert settings.
    
    From-SVN: r240033