This adds a test to make sure we define _WCHAR_T_DEFINED and
_NATIVE_WCHAR_T_DEFINED correctly in the preprocessor, and updates
stddef.h to set it when typedeffing wchar_t.
llvm-svn: 180918
- We shouldn't even try to include stdint.h in hosted mode, as the dependency
on even parsing a platforms stdint.h might fail for some targets.
llvm-svn: 179723
implementation of C99's attempt to control the C++ standard. *sigh*
The C99 standard says that certain macros in <stdint.h>, such as SIZE_MAX,
should not be defined when the header is included in C++ mode, unless
__STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS are defined. The C++11 standard
says "Thanks, but no thanks" and C11 removed this rule, but various C library
implementations (such as glibc) follow C99 anyway.
g++ prior to 4.8 worked around the C99 / glibc behavior by defining
__STDC_*_MACROS in <cstdint>, which was incorrect, because <stdint.h> is
supposed to provide these macros too. g++ 4.8 works around it by defining
__STDC_*_MACROS in its builtin <stdint.h> header.
This change makes Clang act like g++ 4.8 in this regard: our <stdint.h> now
countermands any attempt by the C library to implement the undesired C99 rules,
by defining the __STDC_*_MACROS first. Unlike g++, we do this even in C++98
mode, since that was the intent of the C++ committee, matches the behavior
required in C11, and matches our built-in implementation of <stdint.h>.
llvm-svn: 179419
being included in C++. Don't define alignof or alignas in this case. Note that
the C++11 standard is broken in various ways here (it refers to the contents
of <stdalign.h> in C99, where that header did not exist, and doesn't mention
the alignas macro at all), but we do our best to do what it intended.
llvm-svn: 175708
Xcode-style clang builds only support Xcode's architectures, so mips
isn't available and the driver tries to use gcc instead. cc1 will go
ahead and do -fsyntax-only for any platform it knows about even if it
can't actually compile.
llvm-svn: 164742
This also adds a definition for uint64_t, which was causing build failures
on some platforms. (I'm actually surprised this didn't happen on more
builders, but maybe the search paths are different.)
llvm-svn: 164706
After discussion with several people, including Doug Gregor, we've
decided to change our approach here. If you have questions about this
header file, the commit removing it, etc., please reach out to me
off-list.
llvm-svn: 156322
header, along with a stub test to make sure it compiles in the
appropriate modes.
Thanks to Aaron Ballman for working with me to figure out the initial
strategy here, and to Nico for reviewing and pestering me to actually
commit it.
llvm-svn: 155425
Passing -verify to clang without -cc1 or -Xclang silently passes (with a
printed warning, but lit doesn't care about that). This change adds -cc1 or,
as is necessary in one case, -Xclang to fix this so that these tests are
actually verifying as intended.
I'd like to change the driver so this kind of mistake could not be made, but
I'm not entirely sure how. Further, since the driver only warns about unknown
flags in general, we could have similar bugs with a misspellings of arguments
that would be nice to find.
llvm-svn: 154776
This does not work so well with the -fno-lax-vector-conversions option for
testing the arm_neon.h header but that is a really useful test, so I split
this out to a separate Sema test to check for the warning.
llvm-svn: 120694
stdlib.h. There were numerous problems with forward declaring 'malloc' and
'free', but the most important is that these are reserved by POSIX and may be
implemented via a function-like macro.
As suggested by Dale Johannesen, I'm instead guarding the only include of this
in our builtin headers with __STDC_HOSTED__, and I've removed the include of
the header from the test suite. I'll discuss with folks whether we want to have
a hosted section of the test suite or not, and add it (and perhaps other tests)
back there if that's the direction.
llvm-svn: 119958
'long'. The practical upshot is so that the uint64_t we define in our stdint.h
ends up being compatible with that defined by gcc (at least on Darwin), which
otherwise could lead to type incompatibilities with other system headers.
llvm-svn: 107255
Richard Smith