[cfe-dev] Want input to solve PR18323

[David Wiberg]

2014/1/4 Reid Kleckner <rnk at google.com>:
> So the preprocessed code looks like:
> __m128i __a = ...
> __extension__ ({
>   __m128i __a = (__a);
>   (__m128i)__builtin_ia32_pslldqi128(__a, (count)*8); })
>
> ... making __a uninitialized.  Is that correct?
I think so, yes.

>
> Can you pre-process the source code and upload that to the PR?
Done

>
> I would say that the user is using a double-underscore name which is in the
> implementers namespace and they shouldn't do that.  We can probably go ahead
> and change the name in this instance just to fix the gcc test suite.
The problem is that the name isn't coming from the test suite but from
the libstdc++ implementation of <random> (see the PR for details). As
such I guess there will be more of a discussing regarding who can use
that namespace. What I don't like about just changing the variable
name in the macro is that there is no guarantee that a similar name
clash won't happen again. There's also no warning produced when
compiling since these are considered system headers which make the
problem hard to find.

>
>
> On Fri, Jan 3, 2014 at 4:16 PM, David Wiberg <dwiberg at gmail.com> wrote:
>>
>> Hi all,
>>
>> The file Headers/emmintrin.h contains macros where variables are
>> created inside the macro definition which can cause name collisions
>> and PR18323 shows an example where this has happened. Variables were
>> added to macros in R143792 with comment "Fix vector macros to
>> correctly check argument types. <rdar://problem/10261670>".
>>
>> One way of solving this particular PR is to revert R143792, but since
>> that has led to other problems according to the commit message above
>> I'm not sure if that's the right way and would appreciate other
>> suggestions or comments.
>>
>> / David
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>