Bug 22142 - [powerpc] printf outputs a wrong value of DBL_MAX on ppc64 and ppc64le
Summary: [powerpc] printf outputs a wrong value of DBL_MAX on ppc64 and ppc64le
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.26
: P2 normal
Target Milestone: 2.27
Assignee: Tulio Magno Quites Machado Filho
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-15 13:07 UTC by Tulio Magno Quites Machado Filho
Modified: 2020-11-02 07:45 UTC (History)
1 user (show)

See Also:
Host: powerpc64*-linux-gnu
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tulio Magno Quites Machado Filho 2017-09-15 13:07:23 UTC
Using the following program:

#include <stdio.h>
#include <float.h>

int main() {
                printf("double max = %.8f \n", DBL_MAX);
                printf("double max = %a \n", DBL_MAX);
                        return 0;
}

Outputs:

double max = 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948050016458515597071187135716751514538302097059854097235942464302912735919891897.11953999
double max = 0x1.fffffffffffffp+1023

Instead of:

double max = 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00000000 
double max = 0x1.fffffffffffffp+1023
Comment 1 Tulio Magno Quites Machado Filho 2017-09-15 13:48:17 UTC
Patch submitted to libc-alpha: https://patchwork.sourceware.org/patch/22896/
Comment 2 Sourceware Commits 2017-10-13 19:19:12 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  8644588807215ab09716ac04a150f91ac83acffd (commit)
       via  e8dbd6a36d8e4d30e736e28a364f7a4d1404079a (commit)
       via  179dcdb7af4983fd42824db748ee6cb05f8d71cf (commit)
      from  006e766437033d6565133ce356b55d7b301a7b58 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8644588807215ab09716ac04a150f91ac83acffd

commit 8644588807215ab09716ac04a150f91ac83acffd
Author: James Clarke <jrtc27@jrtc27.com>
Date:   Fri Oct 13 15:44:39 2017 -0300

    Fix TLS relocations against local symbols on powerpc32, sparc32 and sparc64
    
    Normally, TLS relocations against local symbols are optimised by the linker
    to be absolute.  However, gold does not do this, and so it is possible to
    end up with, for example, R_SPARC_TLS_DTPMOD64 referring to a local symbol.
    Since sym_map is left as null in elf_machine_rela for the special local
    symbol case, the relocation handling thinks it has nothing to do, and so
    the module gets left as 0.  Havoc then ensues when the variable in question
    is accessed.
    
    Before this fix, the main_local_gold program would receive a SIGBUS on
    sparc64, and SIGSEGV on powerpc32.  With this fix applied, that test now
    passes like the rest of them.
    
    	* sysdeps/powerpc/powerpc32/dl-machine.h (elf_machine_rela):
    	Assign sym_map to be map for local symbols, as TLS relocations
    	use sym_map to determine whether the symbol is defined and to
    	extract the TLS information.
    	* sysdeps/sparc/sparc32/dl-machine.h (elf_machine_rela): Likewise.
    	* sysdeps/sparc/sparc64/dl-machine.h (elf_machine_rela): Likewise.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=e8dbd6a36d8e4d30e736e28a364f7a4d1404079a

commit e8dbd6a36d8e4d30e736e28a364f7a4d1404079a
Author: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
Date:   Fri Oct 13 15:44:39 2017 -0300

    powerpc: Avoid putting floating point values in memory [BZ #22189]
    
    	[BZ #22189]
    	* sysdeps/powerpc/fpu/math_private.h (math_opt_barrier):
    	(math_force_eval): Add powerpc version.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=179dcdb7af4983fd42824db748ee6cb05f8d71cf

commit 179dcdb7af4983fd42824db748ee6cb05f8d71cf
Author: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
Date:   Fri Oct 13 15:44:39 2017 -0300

    [BZ #22142] powerpc: Fix the carry bit on mpn_[add|sub]_n on POWER7
    
    Fix the ifdef clause that was being used in the opposite way, setting
    a wrong value of the carry bit.
    
    This is also correcting 2 memory accesses that were mistakenly referring
    to r0 while they were supposed to mean the immediate value 0.
    
    	[BZ #22142]
    	* stdio-common/tst-printf.c (fp_test): Add tests for DBL_MAX and
    	-DBL_MAX.
    	(do_test): Likewise.
    	* stdio-common/tst-printf.sh: Likewise.
    	* sysdeps/powerpc/powerpc64/power7/add_n.S: Invert the initial
    	ifdef clause in order to set the carry bit right.  Replace r0 by
    	0 without changing the behavior.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                |   24 ++++++++++++++++++++++++
 stdio-common/tst-printf.c                |    4 ++++
 stdio-common/tst-printf.sh               |    8 ++++++++
 sysdeps/powerpc/fpu/math_private.h       |    7 +++++++
 sysdeps/powerpc/powerpc32/dl-machine.h   |    5 ++++-
 sysdeps/powerpc/powerpc64/power7/add_n.S |    8 ++++----
 sysdeps/sparc/sparc32/dl-machine.h       |    1 +
 sysdeps/sparc/sparc64/dl-machine.h       |    1 +
 8 files changed, 53 insertions(+), 5 deletions(-)
Comment 3 Tulio Magno Quites Machado Filho 2017-10-13 19:21:55 UTC
Fixed in glibc 2.27.
Comment 4 Tulio Magno Quites Machado Filho 2017-10-13 19:22:32 UTC
Fixed, per the previous comment.