Created attachment 11476 [details]
precompile nan test case

Created attachment 11477 [details]
a very simpler test case

afaik don't need precompile (just rebuild) (e.g. gcc -o nan2 Nan2.c; ./nan2)

Why do you think this is a GCC bug?

This isn't a target bug as far as I can tell.  The value generated
by __builtin_nanf("") as shown by Nan2.c is 0x7fc00000.  The same
value is printed on x86.  This is a signaling NaN.  Positive quiet
NaNs range between 0x7f800001 and 0x7fbfffff.

We have the following code for at -02:

.LC0:
        .word   2143289344
        .text
        .align 4
.globl main
        .type   main, @function
main:
        .PROC
        .CALLINFO FRAME=0,CALLS,SAVE_RP
        .ENTRY
        stw %r2,-20(%r30)
        ldil LR'.LC0,%r28
        ldil LR'.LC1,%r26
        ldw RR'.LC0(%r28),%r25
        ldo RR'.LC1(%r26),%r26
        ldw -20(%r30),%r2
        bl printf,%r0
        nop
        nop
        .EXIT

2143289344 is 0x7fc00000 hex.

Created attachment 11481 [details]
just another similar test case regarding double equivalent pb

compile with -O2 the Nan3.s is:
 .LEVEL 1.1
 .section .rodata.str1.4,"aMS",@progbits,1
 .align 4
.LC1:
.stringz"__builtin_nan(): 0x%llx.\n"
 .section .rodata.cst8,"aM",@progbits,8
 .align 8
.LC0:
 .word 2146959360
 .word 0
 .text
 .align 4
.globl main
 .type main, @function
main:
 .PROC
 .CALLINFO FRAME=0,CALLS,SAVE_RP
 .ENTRY
 stw %r2,-20(%r30)
 ldil LR'.LC0,%r28
 ldil LR'.LC1,%r26
 ldw RR'.LC0(%r28),%r23
 ldw RR'.LC0+4(%r28),%r24
 ldo RR'.LC1(%r26),%r26
 ldw -20(%r30),%r2
 bl printf,%r0
 nop
 nop
 .EXIT
 .PROCEND
 .size main, .-main
 .ident "GCC: (GNU) 4.1.1 20060511 (prerelease) (Debian 4.1.0-4)"

and print out:
__builtin_nan(): 0x7ff8000000000000.

or bin form of 1 32bit word: 01111111111110000000000000000000

i.e.
- the first bit being the sign == 0
- next 11 being the exponenent all == 1
- next 52 one being fraction have the first bit == 1, making this NAN a signaling NAN.

And according to this thread (I don't have access to C99 std ;-( ):
<http://gcc.gnu.org/ml/libstdc++/2002-09/msg00030.html>
as well as gcc info
/quote
 -- Built-in Function: double __builtin_nan (const char *str)
     This is an implementation of the ISO C99 function `nan'.

     Since ISO C99 defines this function in terms of `strtod', which we
     do not implement, a description of the parsing is in order.  The
     string is parsed as by `strtol'; that is, the base is recognized by
     leading `0' or `0x' prefixes.  The number parsed is placed in the
     significand such that the least significant bit of the number is
     at the least significant bit of the significand.  The number is
     truncated to fit the significand field provided.  The significand
     is forced to be a quiet NaN.

     This function, if given a string literal, is evaluated early enough
     that it is considered a compile-time constant.
/quote

__builtin_nan[f](""); should return a quiet NAN. To do so, the parisc2.0 doc, says that the fraction part have to be <> 0 but with first bit == 0.

(In reply to comment #4)
> This isn't a target bug as far as I can tell.  The value generated
> by __builtin_nanf("") as shown by Nan2.c is 0x7fc00000.  The same
> value is printed on x86.  This is a signaling NaN.  Positive quiet
> NaNs range between 0x7f800001 and 0x7fbfffff.

Incorrect.  The canonical QNaN on x86 (and most other targets) is
0x7fc00000.  It would seem that PA has the same reversed quiet bit
as MIPS.  See real_format->qnan_msb_set and mips_ieee_single.

Subject: Re:  __builtin_nanf("") doesn't return a _quiet_ nan on parisc

> ------- Comment #6 from rth at gcc dot gnu dot org  2006-05-23 15:00 -------
> (In reply to comment #4)
> > This isn't a target bug as far as I can tell.  The value generated
> > by __builtin_nanf("") as shown by Nan2.c is 0x7fc00000.  The same
> > value is printed on x86.  This is a signaling NaN.  Positive quiet
> > NaNs range between 0x7f800001 and 0x7fbfffff.
> 
> Incorrect.  The canonical QNaN on x86 (and most other targets) is
> 0x7fc00000.  It would seem that PA has the same reversed quiet bit
> as MIPS.  See real_format->qnan_msb_set and mips_ieee_single.

Interesting.  The HP architecture docments for PA 1.1 and 2.0
state that PA-RISC fully conforms to ANSI/IEEE Std 754-1985, so
I presume that this isn't specified (don't have a copy of the
spec handy), so there's no actual canonical format.  I see this
was something of a point of contention in 754R meetings.

Google tells me that MIPS didn't discriminant in early processors,
then used the same convention as PA-RISC, and finally switched again.
So, don't much like calling this the "mips" format.

Dave

Subject: Re:  __builtin_nanf("") doesn't return a _quiet_ nan on parisc

"dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca  2006-05-23 16:28 -------
| Subject: Re:  __builtin_nanf("") doesn't return a _quiet_ nan on parisc
| 
| > ------- Comment #6 from rth at gcc dot gnu dot org  2006-05-23 15:00 -------
| > (In reply to comment #4)
| > > This isn't a target bug as far as I can tell.  The value generated
| > > by __builtin_nanf("") as shown by Nan2.c is 0x7fc00000.  The same
| > > value is printed on x86.  This is a signaling NaN.  Positive quiet
| > > NaNs range between 0x7f800001 and 0x7fbfffff.
| > 
| > Incorrect.  The canonical QNaN on x86 (and most other targets) is
| > 0x7fc00000.  It would seem that PA has the same reversed quiet bit
| > as MIPS.  See real_format->qnan_msb_set and mips_ieee_single.
| 
| Interesting.  The HP architecture docments for PA 1.1 and 2.0
| state that PA-RISC fully conforms to ANSI/IEEE Std 754-1985, so
| I presume that this isn't specified (don't have a copy of the
| spec handy), so there's no actual canonical format.  I see this
| was something of a point of contention in 754R meetings.

The IEEE--754 specification is a *conceptual model*, not a "physical"
wired format.  As long as the units behave functionally as required,
it should be fine.

-- Gaby

Subject: Bug 27627

Author: danglin
Date: Wed May 24 23:23:10 2006
New Revision: 114059

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114059
Log:
	PR target/27627
	* pa/pa-modes.def: Use mips_single_format, mips_double_format and
	mips_quad_format formats instead of ieee_single_format,
	ieee_double_format and ieee_quad_format formats, respectively.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/pa/pa-modes.def

Subject: Re:  __builtin_nanf("") doesn't return a _quiet_ nan on parisc

> 
> 
> 
> ------- Comment #9 from danglin at gcc dot gnu dot org  2006-05-24 23:23 -------
> Subject: Bug 27627
> 
> Author: danglin
> Date: Wed May 24 23:23:10 2006
> New Revision: 114059
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114059
> Log:
>         PR target/27627
>         * pa/pa-modes.def: Use mips_single_format, mips_double_format and
>         mips_quad_format formats instead of ieee_single_format,
>         ieee_double_format and ieee_quad_format formats, respectively.

You might not want to us MIPS_QUAD format because it is not even close
to IEEE Quad format but instead it is more like the PPC quad format.


-- Pinski

Subject: Re:  __builtin_nanf("") doesn't return a _quiet_ nan on parisc

> > Log:
> >         PR target/27627
> >         * pa/pa-modes.def: Use mips_single_format, mips_double_format and
> >         mips_quad_format formats instead of ieee_single_format,
> >         ieee_double_format and ieee_quad_format formats, respectively.
> 
> You might not want to us MIPS_QUAD format because it is not even close
> to IEEE Quad format but instead it is more like the PPC quad format.

I looked at the struct in real.c and the initialization seemed identical
to the ieee struct except for the qnan_msb_set.  Are you possibly confusing
the mips_extended_format with the mips_quad_format?

Dave

Fixed by patch on trunk.