Op 24 feb. 2012 17:36 schreef "Kai Tietz" het
volgende:
>
> Hmm, well, if Clang doesn't need this define we can guard it in our
> header for it.
It's only problematic when compiling clang itself, it being a builtin
shouldn't be a problem for other code I think.
>
> Otherwise it might be also an
Hmm, well, if Clang doesn't need this define we can guard it in our
header for it.
Otherwise it might be also an option to do in clang an undefine at the
place you mentioned.
Regards,
Kai
PS: All my patches I wanna to see in 4.7 are committed. Also recent
regression in binutils is fixed. So I
I believe my latest 4.7 build (which uses trunk instead of v2.x) has a
conflict with Clang, which defined its builtins inside C++ code (which is
altered by the macro)
I can remedy the problem in Clang by #undef'ing the macro before Clang's
builtins are defined, but before submitting a patch I wond
