public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "bruno at clisp dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sources.redhat.com
Subject: [Bug libc/4586] New: printf crashes on some 'long double' values
Date: Sat, 02 Jun 2007 23:29:00 -0000	[thread overview]
Message-ID: <20070602232912.4586.bruno@clisp.org> (raw)

This program crashes inside printf of a pseudo-zero 'long double' number.

============================== ia64nan.c ================================
#include <float.h>
#include <math.h>
#include <stdio.h>
union u { unsigned int word[4]; long double value; };
#define X x.value

void test (const char *label, union u x)
{
  printf ("%s:\n", label);
  printf ("isnanl: %d %d %d\n", isnanl(X) != 0, !(X == X), !(X >= 0 || X <= 0));
  printf ("isinfl: %d %d\n", isinfl(X) != 0, X + X == X && !(X == 0));
  printf ("printf: %Le %Lg\n", X, X);
  printf ("printf normalized: %Lg\n", X * 1.0L);
  printf ("\n");
}

int main ()
{
  {
    union u x = { { 0x00000000, 0x63333333, 0x00008000, 0x00000000 } };
    test ("unnormalized number", x);
  }

  {
    union u x = { { 0x00000000, 0xC3333333, 0x0000FFFF, 0x00000000 } };
    test ("QNaN", x);
  }

  {
    union u x = { { 0x00000000, 0x83333333, 0x0000FFFF, 0x00000000 } };
    test ("SNaN", x);
  }

  {
    union u x = { { 0x00000000, 0x80000000, 0x0000FFFF, 0x00000000 } };
    test ("Inf", x);
  }

  {
    union u x = { { 0x00000000, 0x40000001, 0x0000ffff, 0x00000000 } };
    test ("Pseudo-NaN", x);
  }

  {
    union u x = { { 0x00000000, 0x00000000, 0x0000ffff, 0x00000000 } };
    test ("Pseudo-Inf", x);
  }

  {
    union u x = { { 0x00000000, 0x00000000, 0x00008004, 0x00000000 } };
    test ("Pseudo-Zero", x);
  }

  return 0;
}
=========================================================================

$ gcc -O -fno-builtin -Wall ia64nan.c
$ ./a.out 
unnormalized number:
isnanl: 0 0 0
isinfl: 0 0
printf: -2.605630e-4932 -2.60563e-4932
printf normalized: -2.60563e-4932

QNaN:
isnanl: 1 1 1
isinfl: 0 0
printf: nan nan
printf normalized: nan

SNaN:
isnanl: 1 1 1
isinfl: 0 0
printf: nan nan
printf normalized: nan

Inf:
isnanl: 0 0 0
isinfl: 1 1
printf: -inf -inf
printf normalized: -inf

Pseudo-NaN:
isnanl: 0 1 1
isinfl: 0 0
printf: -5.948657e+4931 -5.94866e+4931
printf normalized: -5.94866e+4931

Pseudo-Inf:
isnanl: 0 1 1
isinfl: 0 0
printf: -0.000000e+4912 -0e+4912
printf normalized: -0e+4912

Pseudo-Zero:
isnanl: 0 0 0
isinfl: 0 0
Segmentation fault


According to
   Intel IA-64 Architecture Software Developer's Manual, Volume 1:
   Application Architecture.
   5.1.3 "Representation of Values in Floating-Point Registers"
   Table 5-2 "Floating-Point Register Encodings"
   Figure 5-11 "Floating-Point Exception Fault Prioritization"

pseudo-NaNs, pseudo-Infs, pseudo-zeroes "are never produced as a result
of an arithmetic operation", i.e. they may be considered to live outside
the IRRR 754 range of numbers. But it would be nice if printf would not
crash here, because
  1) printf is often used for debugging. This is also the reason why
     printf("%s", NULL) prints "(null)" instead of crashing.
  2) Arithmetic operations on pseudo-NaNs, pseudo-Infs, pseudo-zeroes
     don't cause program crashes, if operations on "signalling NaNs"
     don't cause program crashes (see Figure 5-11, cited above); this
     is the default behaviour, as you can see from the program's output.

Additionally, the printf results for pseudo-NaN and pseudo-Inf should better
be "nan", because these numbers behave like NaNs in comparisons, as you can
see from the program's output.

For comparison: On FreeBSD/ia64, printf of pseudo-NaN, pseudo-Inf, pseudo-zero
yields "nan", "[-]inf", "[-]0" respectively.

-- 
           Summary: printf crashes on some 'long double' values
           Product: glibc
           Version: 2.3.6
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: bruno at clisp dot org
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet: ia64-unknown-linux-gnu
  GCC host triplet: ia64-unknown-linux-gnu
GCC target triplet: ia64-unknown-linux-gnu


http://sourceware.org/bugzilla/show_bug.cgi?id=4586

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


             reply	other threads:[~2007-06-02 23:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-02 23:29 bruno at clisp dot org [this message]
2007-06-03  9:37 ` [Bug libc/4586] " schwab at suse dot de
2007-07-07 19:59 ` cvs-commit at gcc dot gnu dot org
2007-07-07 20:00 ` cvs-commit at gcc dot gnu dot org
2007-07-12 13:31 ` cvs-commit at gcc dot gnu dot org
2007-07-12 15:30 ` cvs-commit at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070602232912.4586.bruno@clisp.org \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).