[Bug testsuite/50485] New: gcc.target/i386/sse4_1-blendps.c fails spuriously on i686

[Bug testsuite/50485] New: gcc.target/i386/sse4_1-blendps.c fails spuriously on i686

[vries at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485

             Bug #: 50485
           Summary: gcc.target/i386/sse4_1-blendps.c fails spuriously on
                    i686
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: vries@gcc.gnu.org


gcc.target/i386/sse4_1-blendps.c fails spuriously for me on i686. Diego Novillo
mentions something similar in http://gcc.gnu.org/ml/gcc/2011-07/msg00296.html.

The test uses an uninitialized var src3. Initializing part of the var makes the
test fail reliably for me with the same failure mode: 
...
Index: sse4_1-blendps.c
===================================================================
--- sse4_1-blendps.c (revision 178880)
+++ sse4_1-blendps.c (working copy)
@@ -64,6 +64,7 @@ TEST (void)
     } src3;
   int i;

+  src3.f[1] = __builtin_nansf ("");
   init_blendps (src1.f, src2.f);

   /* Check blendps imm8, m128, xmm */
...

The test aborts because the assignment 'tmp[1] = src2[1]' changes the Nan:
...
static int
check_blendps (__m128 *dst, float *src1, float *src2)
{
  float tmp[4];
  int j;

  memcpy (&tmp[0], src1, sizeof (tmp));
  for (j = 0; j < 4; j++)
    if ((MASK & (1 << j)))
      tmp[j] = src2[j];

  return memcmp (dst, &tmp[0], sizeof (tmp));
}
...

The assignment is translated as a push/pop on the float stack:
...
#(insn 17 39 42 2 (set (reg:SF 8 st)
#        (mem:SF (plus:SI (reg/v/f:SI 2 cx [orig:65 src2 ] [65])
#                (const_int 4 [0x4])) [3 MEM[(float *)src2_10(D) + 4B]+0 S4
A32])) sse4_1-blendps.c:46 108 {*movsf_internal}
#     (expr_list:REG_DEAD (reg/v/f:SI 2 cx [orig:65 src2 ] [65])
#        (expr_list:REG_EQUIV (mem/s/c:SF (plus:SI (reg/f:SI 20 frame)
#                    (const_int -12 [0xfffffffffffffff4])) [3 tmp+4 S4 A32])
#            (nil))))
    flds    4(%ecx)    # 17    *movsf_internal/1    [length = 3]
...
#(insn 18 15 21 2 (set (mem/s/c:SF (plus:SI (reg/f:SI 7 sp)
#                (const_int 20 [0x14])) [3 tmp+4 S4 A32])
#        (reg:SF 8 st)) sse4_1-blendps.c:46 108 {*movsf_internal}
#     (expr_list:REG_DEAD (reg:SF 8 st)
#        (nil)))
    fstps    20(%esp)    # 18    *movsf_internal/2    [length = 4]
...

By going through the float stack, the signalling Nan turns into a quiet Nan.
That seems to correspond with what is said at
http://stackoverflow.com/questions/2247447/usefulness-of-signaling-nan .

So after the push/pop tmp[1] contains a quiet Nan, while the corresponding part
of dst contains the bit representation of the signalling Nan, the memcmp
returns != 0 and the test aborts.

[Bug testsuite/50485] gcc.target/i386/sse4_1-blendps.c fails spuriously on i686

[vries at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485

--- Comment #1 from vries at gcc dot gnu.org 2011-09-22 12:25:23 UTC ---
Created attachment 25339
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25339
proprocessed sse4_1-blendps.c with patch applied to make failure reproducible

To reproduce:
$ i686-pc-linux-gnu-gcc sse4_1-blendps.c -O2 -msse4.1 -lm -o
./sse4_1-blendps.exe
$ ./sse4_1-blendps.exe 
Aborted

[Bug testsuite/50485] gcc.target/i386/sse4_1-blendps.c fails spuriously on i686

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-09-22 20:41:07 UTC ---
I get this failure also.  At first I thought it was my patch and then I noticed
no code changes with my change.

[Bug testsuite/50485] gcc.target/i386/sse4_1-blendps.c fails spuriously on i686

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> 2011-09-22 20:47:01 UTC ---
(In reply to comment #0)

> 
> The assignment is translated as a push/pop on the float stack:
> ...
...
> 
> So after the push/pop tmp[1] contains a quiet Nan, while the corresponding part
> of dst contains the bit representation of the signalling Nan, the memcmp
> returns != 0 and the test aborts.

I think it is wrong to convert memcpy to push/pop here.

[Bug testsuite/50485] gcc.target/i386/sse4_1-blendps.c fails spuriously on i686

[vries at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485

--- Comment #4 from vries at gcc dot gnu.org 2011-09-22 22:11:37 UTC ---
H.J.,

> I think it is wrong to convert memcpy to push/pop here.

Just to be clear here. It's the assignment 'tmp[1] = src2[1]' that gets
translated into the push/pop. The call to memcpy is expanded into SI mode
moves.

Do you mean you think it's wrong to convert the assignment 'tmp[1] = src2[1]'
into push/pop?

Thanks,
- Tom

[Bug testsuite/50485] gcc.target/i386/sse4_1-blendps.c fails spuriously on i686

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> 2011-09-22 22:37:41 UTC ---
(In reply to comment #4)
> H.J.,
> 
> > I think it is wrong to convert memcpy to push/pop here.
> 
> Just to be clear here. It's the assignment 'tmp[1] = src2[1]' that gets
> translated into the push/pop. The call to memcpy is expanded into SI mode
> moves.
> 
> Do you mean you think it's wrong to convert the assignment 'tmp[1] = src2[1]'
> into push/pop?
> 

In this case, src2 should be initialized.

[Bug testsuite/50485] gcc.target/i386/sse4_1-blendps.c fails spuriously on i686

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-09-25
     Ever Confirmed|0                           |1

[Bug testsuite/50485] gcc.target/i386/sse4_1-blendps.c fails spuriously on i686

[mkuvyrkov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485

Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mkuvyrkov at gcc dot
                   |                            |gnu.org

--- Comment #6 from Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> 2011-09-28 00:10:25 UTC ---
I'm also getting this failure with yesterday mainline.  

Isn't the problem here that SRC3 is used uninitialized in _mm_blend_ps? 

The test case is buggy, and Tom's patch initializes SRC3 to a value that
triggers the bug reliably.  I really want to fix this to avoid someone else
(beyond Tom, Andrew and myself) wasting their time on debugging a
non-deterministic test case.

H.J., as you the author of the test case, would you please look into what
changes are need to fix it?  Is it intended that SRC3.X is used uninitialized?

Thank you.

[Bug testsuite/50485] gcc.target/i386/sse4_1-blendps.c fails spuriously on i686

[vries at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485

--- Comment #7 from vries at gcc dot gnu.org 2011-09-28 08:48:05 UTC ---
Author: vries
Date: Wed Sep 28 08:48:00 2011
New Revision: 179309

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179309
Log:
2011-09-28  Tom de Vries  <tom@codesourcery.com>

    PR testsuite/50485
    * gcc.target/i386/sse4_1-blendps.c: Include <stdlib.h>.
    (TEST): Initialize src3 with random floats.
    * gcc.target/i386/sse4_1-blendps-2.c (sse4_1_test): Remove field i from
    union src3.  Initialize src3 with random floats.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.target/i386/sse4_1-blendps-2.c
    trunk/gcc/testsuite/gcc.target/i386/sse4_1-blendps.c

[Bug testsuite/50485] gcc.target/i386/sse4_1-blendps.c fails spuriously on i686

[vries at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
         AssignedTo|unassigned at gcc dot       |vries at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #8 from vries at gcc dot gnu.org 2011-09-28 08:50:33 UTC ---
patch committed, closing bug.