[llvm-bugs] [Bug 29077] New: More complex analysis for -Wuninitialized

via llvm-bugs llvm-bugs at lists.llvm.org
Sat Aug 20 15:28:53 PDT 2016


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

            Bug ID: 29077
           Summary: More complex analysis for -Wuninitialized
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: lebedev.ri at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 17019
  --> https://llvm.org/bugs/attachment.cgi?id=17019&action=edit
Reduced testcase

Manually reduced from babl conv_y8_yF() function:


#include <stdint.h>
#include <smmintrin.h>

void x1()
{
  __m128i x2;
  x2 = _mm_insert_epi32 (x2, 0, 0);
  x2 = _mm_cvtepu8_epi32 (x2);
}


It stores some integer in first element of a 4-component vector, and
then _mm_cvtepu8_epi32() "Zero extends packed unsigned 8-bit integers in a to
packed 32-bit integers, and store the results in x2."

So it is pretty clear that there is no actual read/use of uninitialized values.
It would be awesome if clang would be so smart not to warn here.


Currently it fails with:

complex-uninitialized.c:7:26: warning: variable 'x2' is uninitialized when used
here [-Wuninitialized]
  x2 = _mm_insert_epi32 (x2, (uint32_t) 0, 0);
                         ^~
/usr/lib/llvm-4.0/bin/../lib/clang/4.0.0/include/smmintrin.h:225:70: note:
expanded from macro '_mm_insert_epi32'
                                   ({ __v4si __a = (__v4si)(__m128i)(X); \
                                                                     ^
complex-uninitialized.c:6:3: note: variable 'x2' is declared here
  __m128i x2;
  ^

-- 
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/20160820/8ed7fc0c/attachment.html>


More information about the llvm-bugs mailing list