[cfe-dev] Want input to solve PR18323

[Reid Kleckner]

On Sat, Jan 4, 2014 at 3:14 PM, David Wiberg <dwiberg at gmail.com> wrote:

> 2014/1/4 Reid Kleckner <rnk at google.com>:
> > Interesting.  Here's the libstdc++ code that uses __a:
> >
> http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/api/a01396_source.html#l00055
> >
> > Ted Kremenek added pragmas that silence warnings about this in October:
> >
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/emmintrin.h?r1=192143&r2=192142&pathrev=192143
> >
> > The only way I can think of to fix this with the type checking is to use
> a
> > helper like:
> >
> > static inline always_inline,nodebug __m128i __check_type_m128i(__m128i
> __a)
> > { return __a; }
> > #define _mm_slli_si128(a, __sl2) \
> > (__m128i)__builtin_ia32_pslldqi128(__check_type_m128i(a), (count)*8)
> >
> Thanks for the suggestion. I tested it and it seems to work
> (check-clang and test-case in PR passes). There are quite a few macros
> in the lib\Header files which have potential for this kind of
> name-clash (>100). I think it's a good idea to fix them all but I
> would like some reassurance that this is the correct path before
> attempting this. Are there any more tests that I should perform? Where
> should these kind of helper functions be placed since they are needed
> in multiple intrinsic files?


This approach has the downside that we're injecting a whole bunch of names
into the global namespace, which is annoying.  We still have to hope the
user doesn't shadow the function name.  It might be better to make the
local variable name longer and more obscure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140104/a307b6e4/attachment.html>