patch about compile R with clang

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?

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