Compilation failure of texlive: a bug in clang or application code?

[Joshua Root]

On 2013-1-15 02:10 , Mojca Miklavec wrote:
> One of the main developers of TeX Live argued with the following:
> 
>> the corresponding code in
>>   /usr/lib/gcc/ix86-linux-gnu/4.7.2/include/emmintrin.h:597ff
>> reads
>>
>> extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
>> __artificial__))
>> _mm_set_epi8 (char __q15, char __q14, char __q13, char __q12,
>>               char __q11, char __q10, char __q09, char __q08,
>>               char __q07, char __q06, char __q05, char __q04,
>>               char __q03, char __q02, char __q01, char __q00)
>> {
>>   return __extension__ (__m128i)(__v16qi){
>>     __q00, __q01, __q02, __q03, __q04, __q05, __q06, __q07,
>>     __q08, __q09, __q10, __q11, __q12, __q13, __q14, __q15
>>   };
>>
>> and I'd say that clang must not usurpate user space variables such as b0,
>> b1, b2, etc.  It is certainly legitimate to #define them to whatever is
>> useful for the user code.  So this is a bug in clang!
>>
>> Regards
>> Peter
> 
> So my question is basically: can this be considered a bug in clang and
> if so: what would be the best place to report it to? (And if not, is
> anyone willing to take a look to see if there's an easy workaround
> before the port maintainer gets bitten by this issue?)

I'd have to look up exactly what the standards say (or don't say) about
it, but my immediate thought is that defining macros before including
system headers is always fraught with danger. As you can see above, the
exact same problem would occur with gcc if __q00 were #defined instead
of b0.

Even if the standards don't prescribe prefixing everything in system
headers that could possibly be affected by a user macro with __ or
whatever (which I doubt since that includes stuff like struct member
names), the clang folks may be interested in using names that are less
likely to conflict anyway, since it is affecting real-world code.

The places to report would be:
<https://bugreport.apple.com/>
<http://llvm.org/bugs/>

- Josh