[PATCH] [PATCH] clang internal library headers changes for C++ modules

[Sean Silva]

================
Comment at: lib/Headers/mm_malloc.h:27-33
@@ -26,3 +26,9 @@
 
-#include <stdlib.h>
+#ifdef __cplusplus
+extern "C" void free(void *);
+extern "C" void *malloc(__SIZE_TYPE__);
+#else
+void free(void *);
+void *malloc(__SIZE_TYPE__);
+#endif
 
----------------
rsmith wrote:
> The intended layering is that Clang's `_Builtin_intrinsics` module is a layer on top of the C standard library module. Does that not work in your setup? (Does the module defining <stdlib.h> contain a header that includes these intrinsics headers?)
I think this is a quirk of how I bootstrapped modules on PS4.

My first target for modularization (after measuring where we were spending time parsing) was a vector math library that only depended on the intrinsics (not mm_malloc though). So initially I just needed vector math lib -> _Builtin_intrinsics and this was a way to work around the issues I was seeing (and I guess we've just been doing this ever since). Going back now, it looks like there is a relatively self-contained part of the system headers that reference the intrinsics and can be split out into their own top-level module so that we can use the layering you describe.

================
Comment at: lib/Headers/stdarg.h:29
@@ -28,1 +28,3 @@
 
+#include <_gnuc_va_list.h>
+
----------------
rsmith wrote:
> Can you say a bit more about why this split is useful to you? Do you want to include this part of <stdarg.h> and not the rest, and if so, why?
> 
> It looks to me like we have a more fundamental problem with our <stdarg.h>; like <stddef.h> it appears to be intended that glibc can request individual pieces of it with `__need_*` macros -- or at least, if `__need___va_list` is defined, we're supposed to vend a `__gnuc_va_list` typedef and nothing else.
> 
> So I think we should rearrange this header to properly handle `__need___va_list` in general, and the behavior you want here (to be able to produce `__gnuc_va_list` only) will naturally fall out from that.
John, what error were you seeing that necessitated this? I just did some micro-testing and it seems that clang will actually merge a duplicated definition here.

http://reviews.llvm.org/D9229

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/