clang is compiler http://clang.llvm.org, it is fast and better c compiler then gcc, yesterday i use clang and gfortran compile R. The only two change in source code is : 1. the configure file (in confiure when test include wctype.h,gcc can compile but clang need include both wchar.h wctype.h),so this is patch --- /r/configure +++ /myr/configure @@ -39172,6 +39172,7 @@ cat >>conftest.$ac_ext <<_ACEOF /* end confdefs.h. */ $ac_includes_default +#include <wchar.h> #include <$ac_header> _ACEOF rm -f conftest.$ac_objext @@ -39480,6 +39481,7 @@ cat confdefs.h >>conftest.$ac_ext cat >>conftest.$ac_ext <<_ACEOF /* end confdefs.h. */ +#include <wchar.h> #include <wctype.h> #ifdef F77_DUMMY_MAIN 2. edit tre-match-approx.c change the following line #define __USE_STRING_INLINES #undef __NO_INLINE__ to //#define __USE_STRING_INLINES //#undef __NO_INLINE__ becasue clang will report errors(fields must have a constant size:'variable length array in structure' extension will never be supported' in string.h)
patch about compile R with clang
2 messages · Gong Yu, Brian Ripley
configure is a generated file, and so should not be edited directly. You have not told us what version of R these patches were against, but it looks to me as if wchar.h is included already in current R (R-patched/R-devel) -- certainly in the second case before wctype.h. (It really should not be needed according to POSIX, but it was on MinGW-w64. Also, headers are an issue not just for a compiler but an OS, and you have not told use that either.) So can you please clarify what version of R, what OS, and what changes you think might be needed to m4/R.m4 in the R-devel version of R?
On Mon, 22 Feb 2010, Gong Yu wrote:
clang is compiler http://clang.llvm.org, it is fast and better c compiler then gcc, yesterday i use clang and gfortran compile R.
Hmm, it claims to be 'faster and better', but past reports on Mac OS X (it ships with Snow Leopard) suggested those claims to be exaggerated. (It did not create as fast an R, although it compiled faster, and its error messages were markedly worse than other compilers despite claims to the contrary.)
The only two change in source code is : 1. the configure file (in confiure when test include wctype.h,gcc can compile but clang need include both wchar.h wctype.h),so this is patch --- /r/configure +++ /myr/configure @@ -39172,6 +39172,7 @@ cat >>conftest.$ac_ext <<_ACEOF /* end confdefs.h. */ $ac_includes_default +#include <wchar.h> #include <$ac_header> _ACEOF rm -f conftest.$ac_objext @@ -39480,6 +39481,7 @@ cat confdefs.h >>conftest.$ac_ext cat >>conftest.$ac_ext <<_ACEOF /* end confdefs.h. */ +#include <wchar.h> #include <wctype.h> #ifdef F77_DUMMY_MAIN 2. edit tre-match-approx.c change the following line #define __USE_STRING_INLINES #undef __NO_INLINE__ to //#define __USE_STRING_INLINES //#undef __NO_INLINE__ becasue clang will report errors(fields must have a constant size:'variable length array in structure' extension will never be supported' in string.h)
Please use C comments not C++ ones: we prefer but do not require C99. At least on my version of Linux (Fedora 12), these optimizations are only supposed to be used with 'GNU CC', and are inside a test for __GNUC__ >= 2. So if clang is using them, this is a bug in clang (we have seem similar things with the Intel CC masquerading as GCC). Your OS may differ, of course.
Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595