I think what is happening here is that the default (compiler rather than and therefore perl) FP exception handling mode is "No exceptions". So, any time a #SNaN value is loaded (or generated) in an XMM register, it is silently converted (SNaN | 0008000000000000H )to a #QNaN by the FPU.

But, do not take my word for it; this (FP exception handling) has to be one of the most confusing areas of modern computing. Part of the problem is that once you move away from the old x87/MMX registers to the SSE2/3/4/5/AVX et. al; where anything from 2 to 8 floating point computations are being carried out in parallel, compliance with the IEEE754 exception handling rules -- conceived long before SIMD instruction sets became the norm -- becomes very problematic.

Specifically, the requirement that user exception handlers be provided with the excepting value. Reasonably simple when each FP op produces in one result; much harder when you have 2, 4 or 8 operations being performed and none, some or all could results in an exceptional value. Basically, Intel's (and AMD's) manuals suggest that if compiler writers want to provide FP exception handling and full IEEE compliance, then they would need to provide floating point emulation in the exception handler in order to reproduce the excepting value(s):

E.4.1 Floating-Point Emulation

Every operating system must provide a kernel level floating-point exception handler (a template was presented in Section E.2, “Software Exception Handling” above). In the following discussion, assume that a user mode floating-point exception filter is supplied for SIMD floating-point exceptions (for example as part of a library of C functions), that a user program can invoke in order to handle unmasked exceptions. The user mode floating-point exception filter (not shown here) has to be able to emulate the subset of SSE/SSE2/SSE3 instructions that can generate numeric exceptions, and has to be able to invoke a user provided floating-point exception handler for floating-point exceptions. When a floating-point exception that is not masked is raised by an SSE/SSE2/SSE3 instruction, the low-level floating-point exception handler will be called. This low-level handler may in turn call the user mode floating-point exception filter. The filter function receives the original operands of the excepting instruction as no results are provided by the hardware, whether a pre-computation or a post-computation exception has occurred.

For the full skinny -- but be warned, it makes the 'What Every Computer Scientist Should Know About Floating-Point Arithmetic' paper look like a Donald Trump sound-bite; and about as useful -- see (pdf)Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1:Basic Architecture; Appendices: C & E

And I welcome your correction of my interpretation. :)