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

[Mojca Miklavec]

Dear MacPorts wizards,

This is a "preliminary problem". I have problems compiling the trunk
version of software that's already part of MacPorts (only an older
version), but it is not clear to me if the one to be blamed are clang
header files or the software that fails to compile.

I'm asking now because it would make sense to solve the issue before
the release that's expected somewhere between March and June. XeTeX
(http://sourceforge.net/projects/xetex/,
http://xetex.git.sourceforge.net or
http://tug.org/svn/texlive/trunk/Build/source/) finally builds under
x86_64 without patching (earlier it didn't compile at all and the
current version in MacPorts disables part of the functionality that
depends on Carbon libraries for handling AAT). The modifications are
not 100% finished yet, but the sources are building fine with
llvm-gcc-4.2.

The problem is that an ancient code from TeX Live and some clang
libraries clash with each other when loading Carbon (or CoreServices &
ApplicationServices).

The problematic code is the following (around line 1100 of
/usr/lib/clang/3.1/include/emmintrin.h):

static __inline__ __m128i __attribute__((__always_inline__, __nodebug__))
_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)
{
  return (__m128i)(__v16qi){ b0, b1, b2, b3, b4, b5, b6, b7, b8, b9,
b10, b11, b12, b13, b14, b15 };
}

clashing with
    #define b0 u.B0
    #define b1 u.B1
    #define b2 u.B2
    #define b3 u.B3
from
    http://tug.org/svn/texlive/trunk/Build/source/texk/web2c/texmfmem.h?view=markup


The reported error is:

In file included from ../../../texk/web2c/xetexdir/XeTeX_ext.c:57:
In file included from ./xetexd.h:571:
In file included from ./xetexcoerce.h:1202:
In file included from ../../../texk/web2c/xetexdir/xetex.h:103:
In file included from ../../../texk/web2c/xetexdir/XeTeXOTMath.h:36:
In file included from ../../../texk/web2c/xetexdir/XeTeX_ext.h:78:
In file included from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20:
In file included from
/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21:
In file included from
/System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20:
In file included from
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:129:
In file included from
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32:
In file included from
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MachineExceptions.h:29:
In file included from /usr/bin/../lib/clang/3.1/include/xmmintrin.h:985:
/usr/bin/../lib/clang/3.1/include/emmintrin.h:1100:133: 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)

                                                             ^
../../../texk/web2c/texmfmem.h:171:13: note: expanded from macro 'b3'
#define b3 u.B3
            ^
/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:1102:30: error: member
reference base type 'char' is not a structure or union
  return (__m128i)(__v16qi){ b0, b1, b2, b3, b4, b5, b6, b7, b8, b9,
b10, b11, b12, b13, b14, b15 };
                             ^~
../../../texk/web2c/texmfmem.h:168:14: note: expanded from macro 'b0'
#define b0 u.B0
           ~ ^


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?)

Mojca