<div dir="ltr">Interesting.  Here's the libstdc++ code that uses __a:<div><a href="http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/api/a01396_source.html#l00055" target="_blank">http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/api/a01396_source.html#l00055</a><br>

</div><div><br></div><div>Ted Kremenek added pragmas that silence warnings about this in October:</div><div><a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/emmintrin.h?r1=192143&r2=192142&pathrev=192143" target="_blank">http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/emmintrin.h?r1=192143&r2=192142&pathrev=192143</a><br>

</div><div class="gmail_extra"><br></div><div class="gmail_extra">The only way I can think of to fix this with the type checking is to use a helper like:</div><div class="gmail_extra"><br></div><div class="gmail_extra">static inline always_inline,nodebug __m128i __check_type_m128i(__m128i __a) { return __a; }</div>
<div class="gmail_extra">#define <span style="color:rgb(0,0,0);white-space:pre-wrap">_mm_slli_si128(a, __sl2) \</span></div><div class="gmail_extra"><span style="color:rgb(0,0,0);white-space:pre-wrap">  </span><span style="color:rgb(0,0,0);white-space:pre-wrap">(__m128i)__builtin_ia32_pslldqi128(__check_type_m128i(a), (count)*8)</span></div>
<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 3, 2014 at 5:29 PM, David Wiberg <span dir="ltr"><<a href="mailto:dwiberg@gmail.com" target="_blank">dwiberg@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">2014/1/4 Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>>:<br>

<div>> So the preprocessed code looks like:<br>
> __m128i __a = ...<br>
> __extension__ ({<br>
>   __m128i __a = (__a);<br>
>   (__m128i)__builtin_ia32_pslldqi128(__a, (count)*8); })<br>
><br>
> ... making __a uninitialized.  Is that correct?<br>
</div>I think so, yes.<br>
<div><br>
><br>
> Can you pre-process the source code and upload that to the PR?<br>
</div>Done<br>
<div><br>
><br>
> I would say that the user is using a double-underscore name which is in the<br>
> implementers namespace and they shouldn't do that.  We can probably go ahead<br>
> and change the name in this instance just to fix the gcc test suite.<br>
</div>The problem is that the name isn't coming from the test suite but from<br>
the libstdc++ implementation of <random> (see the PR for details). As<br>
such I guess there will be more of a discussing regarding who can use<br>
that namespace. What I don't like about just changing the variable<br>
name in the macro is that there is no guarantee that a similar name<br>
clash won't happen again. There's also no warning produced when<br>
compiling since these are considered system headers which make the<br>
problem hard to find.<br>
<div><div><br>
><br>
><br>
> On Fri, Jan 3, 2014 at 4:16 PM, David Wiberg <<a href="mailto:dwiberg@gmail.com" target="_blank">dwiberg@gmail.com</a>> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> The file Headers/emmintrin.h contains macros where variables are<br>
>> created inside the macro definition which can cause name collisions<br>
>> and PR18323 shows an example where this has happened. Variables were<br>
>> added to macros in R143792 with comment "Fix vector macros to<br>
>> correctly check argument types. <rdar://problem/10261670>".<br>
>><br>
>> One way of solving this particular PR is to revert R143792, but since<br>
>> that has led to other problems according to the commit message above<br>
>> I'm not sure if that's the right way and would appreciate other<br>
>> suggestions or comments.<br>
>><br>
>> / David<br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>