[LLVMbugs] [Bug 24230] New: [powerpc-ubuntu] miscompilation on opencl for long/ulong vector data types

[bugzilla-daemon at llvm.org]

https://llvm.org/bugs/show_bug.cgi?id=24230

            Bug ID: 24230
           Summary: [powerpc-ubuntu] miscompilation on opencl for
                    long/ulong vector data types
           Product: new-bugs
           Version: 3.6
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: kanagak86 at yahoo.ca
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 14636
  --> https://llvm.org/bugs/attachment.cgi?id=14636&action=edit
miscompilation on long/ulong vector datatypes

Miscompilation for long/ulong data types computation with vector sizes more
than 1 (ie. long2/ulong2, long3/ulong3, long4/ulong4 and etc.)

Bug was reproducible on all 3.6.1 and 3.6.2 (latest 3.6.2 r242926). 

The last revision it worked on was 3.6 r222776. 

Here's more detail explanation of possible way to reproduce the problem. Also,
I have attached file generated from bugpoint.

For example: 
------------
Description: For each component of a vector type, result[i] = if MSB of c[i] is
set ? b[i] : a[i]. In our example, to avoid branch, we're using the following
tricks to get the result. 

Code Snip
---------
static inline ulong4 __attribute__((overloadable)) select(ulong4 a,ulong4
b,long4 c)
{
    long4 msb = (c & ((long4)0x8000000000000000));
    return (as_ulong4(msb == (long4)(0x0)) & a) | (as_ulong4(msb ==
(long4)(0x8000000000000000)) & b);
}

Output: 
-------
ulong4: 0) select(2442926672567622827, 3967573090254568380,
-5840417280764598375) expected 3967573090254568380 got 3967573092447682495
ulong4: 1) select(-8456079605802066238, -406108156188768074,
-6400753874706939934) expected -406108156188768074 got -406108156087836938
ulong4: 2) select(-3206018145846460440, 4990307068426073364,
-493767623234204525) expected 4990307068426073364 got 4990307068565880828

It seems like the "expected" value and "got" value is pretty similar. Closely
looking at it, the last 4 Bytes are being manipulated.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150723/8a6ae056/attachment.html>