Yes - how do we conclusively determine whether the bug is in the assigning, or in the retrieving ?

The best I can think of is the IC code below. It returns an SV that has SvNOK set and the NV contains an SNaN bit pattern.

It does two things that are a bit trick (and non-portable to earlier (<5.10) builds because of changes to perl's internal structures over the last several builds.)

1. It assigns the bit pattern to the NV field of the SV directly, bypassing any/all internal macros that might mess with it.
2. It points the PV pointer at the memory containing the NV allowing direct access from perl without unpack 'd'/'F'

It *may* be possible to port it to gcc/32-bit?

#! perl -slw
use strict; use Config;
use Inline C => Config => BUILD_NOISY => 1, CCFLAGS => $Config{ccflags
+}." -DDEBUG=1";
use Inline C => <<'END_C',  NAME => 'ICexample', CLEAN_AFTER_BUILD =>0
+;

static const unsigned __int64 i = 0x7ff0000000000001;

SV*snan2() {
    // Allocate a new SvPV with some junk pv data
    SV *ret = newSVpvn( "JustJunk", 8 );

    // Assign the SNaN bit pattern directly to the NV field bypassing 
+any dodgy macros
    *(unsigned __int64*)&( ( (XPVNV*)ret->sv_any )->xnv_u.xnv_nv ) = i
+;

    // Set the NOK flag
    SvNOK_on( ret );

    // Now point the PV pointer directly at the NV memory so we can ac
+cess it
    // (the NV) from perl without going through pack 'd'/'F'
    SvPV_set( ret, (char*)&( ( (XPVNV*)ret->sv_any )->xnv_u.xnv_nv ) )
+;

    // make it persist
    SvREFCNT_inc_void_NN( ret );
    
    // Make sure noone can mess with it.
    SvREADONLY( ret );
    return ret;
}

END_C

## Get an SNAN.
my $snan2 = snan2();

##Print its numeric value AND its bit pattern bypassing SVNV?()
printf "%f\n%x\n", $snan2, unpack 'Q', $snan2;

## Same thing as the printf '%x', unpack 'Q' above
## that *might* work on 32-bit that doesn't have Q
print scalar reverse unpack 'h*', $snan2;

__END__
C:\test>snan-ic.pl
1.#SNAN0
7ff0000000000001
7ff0000000000001
[download]

The best I can think of is the IC code below

It allows me to get the same output as you, but I don't know that it proves the problem is in SvNV() because it also avoids sv_setnv().
And I've been assuming that the problem is inside sv_setnv().

I'll post a bug report (referencing this thread) later today and report the developments from that report back to this thread.

In the meantime, I'm happy to continue this discussion - though my thick skull may continue to defy the penetration of the points you make ;-)

With the code you just provided, running Devel::Peek::Dump($snan); crashes - which is a pity, because I would have liked to see more of what is in that variable.
And print $snan; outputs the same as pack 'd' done on a signalling NaN (that has the 7ff0000000000001 format).
The last line of code crashes for me (on a 32-bit perl that has quad formatting) - but that's no issue as the previous code had displayed:

NaN
7ff0000000000001
[download]

and it was nice to see 7ff0000000000001 for a change.

The CCFLAGS setting in the I::C config has no impact afaict. (I assume it's a leftover from a previous exercise - and mention it only in case it should have provided something significant.)

Cheers,
Rob