| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 212987
|
| |
|
|
|
|
|
|
| |
corresponding AST context function, only restricted to basic integer
types. Use this to ensure getUIntPtrType() gives types consistent with
getIntPtrType(). Fix NVPTX backend to give signed intptr_t.
llvm-svn: 212982
|
| |
|
|
|
|
| |
Also consolidate 'backward compatibility'
llvm-svn: 212974
|
| |
|
|
| |
llvm-svn: 212804
|
| |
|
|
|
|
| |
isn't supported in MSVC.
llvm-svn: 212754
|
| |
|
|
|
|
|
|
|
|
| |
TargetInfo,DescriptionString, flags, paths lookup, etc. Cover changes with new tests. The author of the patch is Pavel Chupin (@pavel.v.chupin).
The changes enable "hello world" on x32 target (x86_64-*-linux-gnux32). s/isX32/IsX32/ also fixed.
Differential Revision: http://reviews.llvm.org/D4180
llvm-svn: 212725
|
| |
|
|
|
|
|
|
|
|
|
|
| |
correctly on MIPS32r6/MIPS64r6
Summary:
This removes the need to pass -mnan=2008 explicitly to be able to compile
the test-suite for MIPS32r6/MIPS64r6.
Differential Revision: http://reviews.llvm.org/D4433
llvm-svn: 212619
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
While debugging another issue, I noticed that Mips currently specifies that the
count leading zero builtins are undefined when the input is zero. The
architecture specifications say that the clz and dclz instructions write 32 or
64 respectively when given zero.
This doesn't fix any bugs that I'm aware of but it may improve optimisation in
some cases.
Differential Revision: http://reviews.llvm.org/D4431
llvm-svn: 212618
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having some kind of weird kernel-assisted ABI for these when the
native instructions are available appears to be (and should be) the
exception; OSs have been gradually opting in for years and the code
was getting silly.
So let LLVM decide whether it's possible/profitable to inline them by
default.
Patch by Phoebe Buckheister.
llvm-svn: 212598
|
| |
|
|
|
|
|
|
|
| |
std::unique_ptr
Spotted after a memory leak (due to the complexities of manual memory
management) was fixed in 212466.
llvm-svn: 212541
|
| |
|
|
| |
llvm-svn: 212516
|
| |
|
|
|
|
| |
Patch by Guochun Shi.
llvm-svn: 212466
|
| |
|
|
| |
llvm-svn: 212453
|
| |
|
|
|
|
| |
The facility was abstracted to LLVM in r187364.
llvm-svn: 212441
|
| |
|
|
| |
llvm-svn: 212408
|
| |
|
|
| |
llvm-svn: 212388
|
| |
|
|
|
|
|
| |
This makes it clear that TargetInfo doesn't capture the LangOptions object,
rather uses it to apply adjustments.
llvm-svn: 212386
|
| |
|
|
| |
llvm-svn: 212339
|
| |
|
|
| |
llvm-svn: 212338
|
| |
|
|
| |
llvm-svn: 212260
|
| |
|
|
|
|
|
|
|
|
| |
This extends the target builtin support to allow language specific annotations
(i.e. LANGBUILTIN). This is to allow MSVC compatibility whilst retaining the
ability to have EABI targets use a __builtin_ prefix. This is merely to allow
uniformity in the EABI case where the unprefixed name is provided as an alias in
the header.
llvm-svn: 212196
|
| |
|
|
|
|
|
|
|
|
| |
The backend *can* cope with all of these now, so Clang should give it the
chance. On CPUs without cmpxchg16b (e.g. the original athlon64) LLVM can reform
the libcalls.
rdar://problem/13496295
llvm-svn: 212173
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are slight differences between /GR- and -fno-rtti which made
mapping one to the other inappropriate.
-fno-rtti disables dynamic_cast, typeid, and does not emit RTTI related
information for the v-table.
/GR- does not generate complete object locators and thus will not
reference them in vftables. However, constructs like dynamic_cast and
typeid are permitted.
This should bring our implementation of RTTI up to semantic parity with
MSVC modulo bugs.
llvm-svn: 212138
|
| |
|
|
|
|
|
|
|
| |
command line option only. Internally we convert them to the "o32" and "n64"
respectively. So we do not need to refer them anywhere after that conversion.
No functional changes.
llvm-svn: 212096
|
| |
|
|
|
|
|
|
|
| |
Windows on ARM defines va_list as a typedef for char *. Although the semantics
of argument passing for variadic functions matches AAPCS VFP, the wrapped
struct __va_list type is unused. This makes the intrinsic definition for
va_list match that of Visual Studio.
llvm-svn: 212004
|
| |
|
|
|
|
|
| |
This corrects the handling for i686-windows-itanium. This environment is nearly
identical to Windows MSVC, except it uses the itanium ABI for C++.
llvm-svn: 211991
|
| |
|
|
|
|
| |
Remove unnecessary separation of anonymous namespace. NFC.
llvm-svn: 211990
|
| |
|
|
|
|
| |
No functional changes.
llvm-svn: 211984
|
| |
|
|
|
|
| |
No functional changes.
llvm-svn: 211983
|
| |
|
|
|
|
| |
No functional changes.
llvm-svn: 211982
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch introduces ACLE header file, implementing extensions that can be directly mapped to existing Clang intrinsics. It implements for both AArch32 and AArch64.
Reviewers: t.p.northover, compnerd, rengolin
Reviewed By: compnerd, rengolin
Subscribers: rnk, echristo, compnerd, aemerson, mroth, cfe-commits
Differential Revision: http://reviews.llvm.org/D4296
llvm-svn: 211962
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes a const_cast added in r211884 that occurred due to an
inconsistency in how MemoryBuffers are handled between some parts of
clang and LLVM.
MemoryBuffers are immutable and the general convention in the LLVM
project is to omit const from immutable types as it's simply
redundant/verbose (see llvm::Type, for example). While this change
doesn't remove "const" from /every/ MemoryBuffer, it at least makes this
chain of ownership/usage consistent.
llvm-svn: 211915
|
| |
|
|
| |
llvm-svn: 211886
|
| |
|
|
|
|
|
|
|
|
|
| |
Get the predefined macro for the architecture correct.
cortex-m4: __ARM_ARCH_7EM__
cortex-m3: __ARM_ARCH_7M__
cortex-m0: __ARM_ARCH_6M__
rdar://17420090
llvm-svn: 211792
|
| |
|
|
| |
llvm-svn: 211778
|
| |
|
|
| |
llvm-svn: 211774
|
| |
|
|
| |
llvm-svn: 211767
|
| |
|
|
|
|
|
|
|
| |
For now, this is only used by its unit tests. It is similar to the API
in llvm::sys::fs::recursive_directory_iterator, but without some of the
more complex features like requesting that the iterator not recurse into
the next directory, for example.
llvm-svn: 211732
|
| |
|
|
| |
llvm-svn: 211685
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add predefined stdint macros that match the given patterns:
U?INT{_,_FAST,_LEAST}{8,16,32,64}_{MAX,TYPE}
U?INT{PTR,MAX}_{MAX,TYPE}
http://reviews.llvm.org/D4141
Author: binji
llvm-svn: 211657
|
| |
|
|
| |
llvm-svn: 211631
|
| |
|
|
|
|
|
|
| |
The API is based on sys::fs::directory_iterator, but it allows iterating
over overlays and the yaml-based VFS. For now, it isn't used by
anything (except its tests).
llvm-svn: 211623
|
| |
|
|
| |
llvm-svn: 211479
|
| |
|
|
|
|
|
|
|
| |
Custom diagnostics don't have a builtin class so this wouldn't have worked.
Reduces surface area of remark-related changes.
No test coverage.
llvm-svn: 211462
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The version information for Visual Studio is spread over multiple variables.
The newer Windows SDK has started making use of some of the extended versioning
variables that were previously undefined. Enhance our compatibility definitions
for these cases.
_MSC_VER is defined to be the Major * 100 + Minor. _MSC_FULL_VER is defined to
be Major * 10000000 + Minor * 100000 + Build. And _MSC_BUILD is the build
revision of the compiler.
Extend the -fmsc-version option in a compatible manner. If the value is the
previous form of MMmm, then we assume that the build number is 0. Otherwise, a
specific build number may be passed by using the form MMmmbbbbb. Due to
bitwidth limitations of the option, it is currently not possible to define a
revision value.
The version information can be passed as either the decimal encoded value
(_MSC_FULL_VER or _MSC_VER) or as a dot-delimited value.
The change to the TextDiagnostic is to deal with the updated encoding of the
version information.
llvm-svn: 211420
|
| |
|
|
| |
llvm-svn: 211352
|
| |
|
|
| |
llvm-svn: 211347
|
| |
|
|
| |
llvm-svn: 211342
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Successfully loaded module files may be referenced in other
ModuleManagers, so don't invalidate them. Two related things are fixed:
1) I thought the last module in the manager was always the one that
failed, but it isn't. So check explicitly against the list of
vetted modules from ReadASTCore.
2) We now keep the file descriptor of pcm file open, which avoids the
possibility of having two different pcms for the same module loaded when
building in parallel with headers being modified during a build.
<rdar://problem/16835846>
llvm-svn: 211330
|
| |
|
|
| |
llvm-svn: 211147
|