On Thu, 2013-12-05 at 18:11 +0100, Jakub Jelinek wrote: > On Thu, Dec 05, 2013 at 12:05:23PM -0500, Jason Merrill wrote: > > On 12/05/2013 10:59 AM, Oleg Endo wrote: > > >On Thu, 2013-12-05 at 10:45 -0500, Jason Merrill wrote: > > >>A simple workaround would be to disable poisoning of malloc/realloc on > > >>OS X (or when the build machine uses libc++, if that's easy to detect). > > > > > >Whether libc++ uses malloc/realloc/free in some implementation in a > > >header file or not is an implementation detail. It could use it today > > >and stop doing so tomorrow ;) > > > > Yep, which is why I described my suggestion as a workaround. :) > > > > But having the poisoning disabled when building with clang doesn't > > seem like a significant problem even if it becomes unnecessary, > > since any misuse will still show up when building stage 2 and on > > other platforms. > > Guess the problem is that clang pretends to be (old) version of GCC. > Otherwise all the poisioning, which is guarded by: > #if (GCC_VERSION >= 3000) > wouldn't be applied. So perhaps we want a hack there && !defined __clang__ > or similar.
The problem is not clang but the exposed internals of libc++ (at least the version Apple currently ships). The problem would be the same if GCC was used as the compiler but with libc++ instead of libstdc++ (it seems some people have been trying to do that, see http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-August/010149.html) BTW, the #include <sstream> in sh.c also triggered the "do_not_use_isalpha_with_safe_ctype" stuff in include/safe-ctype.h, which is a similar problem (isalpha being used in some implementation in libc++). Cheers, Oleg
