================ 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/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
