| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Headers/altivec-header.c to ensure it only runs on ppc64.
llvm-svn: 167162
|
|
|
|
| |
llvm-svn: 167148
|
|
|
|
|
|
| |
VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.
llvm-svn: 166280
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 164683
|
|
|
|
|
|
|
|
| |
system headers for the wrong target.
While there add a test that verifies that the header parses in C++ mode.
llvm-svn: 164679
|
|
|
|
|
|
|
|
| |
In the C programming language, we have to add the
"struct" keyword. Otherwise, the compiler will
emit error message.
llvm-svn: 164665
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Fixes the two issues mentioned in PR12146.
llvm-svn: 155490
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 148582
|
|
|
|
| |
llvm-svn: 148141
|
|
|
|
| |
llvm-svn: 148138
|
|
|
|
|
|
|
| |
- Fixes <rdar://problem/10261246> clang -maes option is not sufficient to
include <wmmintrin.h>
llvm-svn: 145939
|
|
|
|
| |
llvm-svn: 140155
|
|
|
|
|
|
|
|
| |
these should be in stdint.h - and they already are.
Fixes rdar://10097036.
llvm-svn: 139332
|
|
|
|
|
|
| |
include.
llvm-svn: 135766
|
|
|
|
|
|
| |
clang_cc1.
llvm-svn: 135763
|
|
|
|
| |
llvm-svn: 135708
|
|
|
|
|
|
|
| |
The arm_neon.h header includes stdint.h and it picks up the system header
without -ffreestanding.
llvm-svn: 120716
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 120642
|
|
|
|
|
|
|
| |
Make sure the -Wvector-conversions does not cause unnecessary warnings when
using Neon intrinsics with the correct types.
llvm-svn: 120634
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 116888
|
|
|
|
|
|
|
| |
http://llvm.org/viewvc/llvm-project?rev=116771&view=rev) we can get rid of these
hacks.
llvm-svn: 116853
|
|
|
|
|
|
| |
in a GNU-compatible C++ dialect. Fixes <rdar://problem/8477819>.
llvm-svn: 115028
|
|
|
|
|
|
| |
instead. This matches GCC's behavior.
llvm-svn: 111692
|
|
|
|
| |
llvm-svn: 110253
|
|
|
|
|
|
|
|
| |
'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
|
|
|
|
| |
llvm-svn: 107153
|
|
|
|
|
|
| |
we aren't always able to find on Win32.
llvm-svn: 99649
|
|
|
|
| |
llvm-svn: 99634
|
|
|
|
| |
llvm-svn: 99627
|
|
|
|
| |
llvm-svn: 99623
|
|
|
|
| |
llvm-svn: 99200
|
|
|
|
|
|
| |
triple imply sse2?
llvm-svn: 99197
|
|
|
|
| |
llvm-svn: 99190
|
|
llvm-svn: 98008
|