[LLVMbugs] [Bug 14964] New: emmintrin.h: "too simple" variable names

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=14964

             Bug #: 14964
           Summary: emmintrin.h: "too simple" variable names
           Product: clang
           Version: 3.2
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Headers
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mojca.miklavec.lists at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The following minimal example (due to inclusion of CoreServices it probably
compiles just on Mac OS X) works fine with llvm-gcc compiler, but fails with
clang:

#define b0 42
#include <CoreServices/CoreServices.h>

int main()
{
    return 0;
}

Alternative example that could work on other platforms:

#define b0 42
#include <emmintrin.h>

int main()
{
    return 0;
}

The reported error is the following:


In file included from a.c:3:
/usr/bin/../lib/clang/3.1/include/emmintrin.h:1100:160: error: expected ')'
_mm_set_epi8(char b15, char b14, char b13, char b12, char b11, char b10, char
b9, char b8, char b7, char b6, char b5, char b4, char b3, char b2, char b1,
char b0)
                                                                               
                                                                              
^
a.c:1:12: note: expanded from macro 'b0'
#define b0 42
           ^
/usr/bin/../lib/clang/3.1/include/emmintrin.h:1100:13: note: to match this '('
_mm_set_epi8(char b15, char b14, char b13, char b12, char b11, char b10, char
b9, char b8, char b7, char b6, char b5, char b4, char b3, char b2, char b1,
char b0)
            ^
/usr/bin/../lib/clang/3.1/include/emmintrin.h:1100:160: error: parameter name
omitted
_mm_set_epi8(char b15, char b14, char b13, char b12, char b11, char b10, char
b9, char b8, char b7, char b6, char b5, char b4, char b3, char b2, char b1,
char b0)
                                                                               
                                                                              
^
a.c:1:12: note: expanded from macro 'b0'
#define b0 42
           ^

The minimal example above is an artificial one, but it demonstrates a
compilation problem from a real world example (a relatively old part of code
from TeX Live fails to compile with clang, while it has apparently never been a
problem on any of other compilers).

One of the developers of TeX Live who works on Linux 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!

Of course one can argue that user still cannot define __q00, that macro b0
should be renamed to something else, or that the libraries should be loaded in
different order, but at least it is a lot more likely that user variables would
clash with b0 than with __q00.

So I'm not 100% sure if this can be treated as a problem in clang or not, but
it would definitely be nice to choose some less common names for naming the
variables.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.