| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
Visual Studio is the Integrated Development Environment. The toolchain is
generally referred to MSVC. Rename the target information to be more precise as
per the recommendation of Reid Kleckner.
llvm-svn: 205609
|
| |
|
|
|
|
| |
hasAttribute. No functional changes.
llvm-svn: 205201
|
| |
|
|
|
|
|
|
|
|
| |
Clean up the __has_attribute implementation without modifying its behavior.
Replaces the tablegen-driven AttrSpellings.inc, which lived in the lexing layer with AttrHasAttributeImpl.inc, which lives in the basic layer. Updates the preprocessor to call through to this new functionality which can take additional information into account (such as scopes and syntaxes).
Expose the ability for parts of the compiler to ask whether an attribute is supported for a given spelling (including scope), syntax, triple and language options.
llvm-svn: 205181
|
| |
|
|
| |
llvm-svn: 205164
|
| |
|
|
|
|
|
|
|
| |
At least on REL6 (Linux/glibc 2.12), the proper symbol for generating gprof
data is _mcount, not mcount. Prior to this change, compiling with -pg would
generate linking errors (because of unresolved references to mcount), after
this change -pg seems at least minimally functional.
llvm-svn: 205144
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
|
| |
|
|
|
|
| |
Reviewed at http://llvm-reviews.chandlerc.com/D3096
llvm-svn: 205008
|
| |
|
|
|
|
|
|
|
| |
This follows the LLVM change to canonicalise the Windows target triple
spellings. Rather than treating each Windows environment as a single entity,
the environments are now modelled properly as an environment. This is a
mechanical change to convert the triple use to reflect that change.
llvm-svn: 204978
|
| |
|
|
|
|
| |
results, some still have link errors.
llvm-svn: 204974
|
| |
|
|
|
|
| |
with non-MSVC compilers.
llvm-svn: 204968
|
| |
|
|
| |
llvm-svn: 204955
|
| |
|
|
|
|
|
|
| |
Replaces the tablegen-driven AttrSpellings.inc, which lived in the lexing layer with AttrHasAttributeImpl.inc, which lives in the basic layer. Updates the preprocessor to call through to this new functionality which can take additional information into account (such as scopes and syntaxes).
Expose the ability for parts of the compiler to ask whether an attribute is supported for a given spelling (including scope), syntax, triple and language options.
llvm-svn: 204952
|
| |
|
|
|
|
| |
NetBSD/aarch64 to simplify code sharing with NetBSD/arm.
llvm-svn: 204798
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Additional clarification from Uli for the background on _CALL_ELF:
"Historically GCC has provided various _CALL_... predefines depending on the
ABI currently being compiled for. (_CALL_SYSV,_CALL_AIXDESC, _CALL_DARWIN )
When we needed a new define for the current ABI, we decided on using _CALL_ELF
since the official name of the ABI is the OpenPower ElfV2 ABI, with the
current Linux ABI retro-actively being renamed the ELFv1 ABI
and so we decided on using _CALL_ELF to identify the Linux (+BSD etc.) ELF ABI,
with _CALL_ELF=1 for the v1 ABI and _CALL_ELF=2 for the v2 ABI.
(Note that this matches the gcc compiler switch -mabi=elfv1 vs. -mabi=elfv2)."
In code, a (_CALL_ELF==2) check will indicate when the ELFv2 ABI is
to be used. This is the desired default for the PPC64 LE target.
llvm-svn: 204627
|
| |
|
|
|
|
|
|
|
|
| |
Update DataLayout/DescriptionString for ppc64le
Similar LLVM change made in r203664
Testcase included.
llvm-svn: 204613
|
| |
|
|
| |
llvm-svn: 204604
|
| |
|
|
| |
llvm-svn: 204428
|
| |
|
|
| |
llvm-svn: 204196
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since "half" is an OpenCL keyword and clang accepts __fp16 as an extension for
other languages, error messages and metadata (and hence debug info) should refer
to the half-precision floating point as "__fp16" instead of "half" when
compiling for non-OpenCL languages. This patch creates a new printing policy for
half in a similar manner to what is done for bool and wchar_t.
Differential Revision: http://llvm-reviews.chandlerc.com/D2952
llvm-svn: 204164
|
| |
|
|
|
|
| |
overridden itself.
llvm-svn: 203538
|
| |
|
|
|
|
| |
class.
llvm-svn: 203537
|
| |
|
|
|
|
| |
semantics where appropriate.
llvm-svn: 203477
|
| |
|
|
| |
llvm-svn: 203455
|
| |
|
|
| |
llvm-svn: 203389
|
| |
|
|
|
|
| |
blocks when building in C mode, and serialize and deserialize the attribute.
llvm-svn: 203317
|
| |
|
|
|
|
| |
This compiles cleanly with lldb/lld/clang-tools-extra/llvm.
llvm-svn: 203279
|
| |
|
|
|
|
| |
This is a precursor to moving to std::unique_ptr.
llvm-svn: 203275
|
| |
|
|
|
|
| |
Found by -Wunreachable-code.
llvm-svn: 203167
|
| |
|
|
|
|
|
| |
Use the new getObjectFormat/setObjectFormat instead of Environment now that the
file format is a separate field.
llvm-svn: 203161
|
| |
|
|
| |
llvm-svn: 203087
|
| |
|
|
|
|
|
| |
Using a //net/ path to hopefully avoid problems with non-absolute paths
on Windows.
llvm-svn: 203010
|
| |
|
|
|
|
|
|
|
| |
Use llvm::sys::fs::make_absolute to get an absolute path before
matching. Also, allow "." directories to enable testing. ".." is still
not supported, and will require crossing file system boundaries to
implement correctly.
llvm-svn: 202903
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for the PPC "wc" inline asm constraint (used for allocating
individual CR bits). Support for this constraint type was recently added to the
LLVM PowerPC backend. Although gcc does not currently support allocating
individual CR bits, this identifier choice has been coordinated with the gcc
PowerPC team, and will be marked as reserved for this purpose in the gcc
constraints.md file.
Prior to this change, none of the multi-character PPC constraints were handled
correctly (the '^' escape character was not being added as required by the
parsing code in LLVM). This should now be fixed. I'll add tests for these other
constraints as support is added for them in the backend.
llvm-svn: 202658
|
| |
|
|
|
|
| |
No intended functionality change.
llvm-svn: 202652
|
| |
|
|
| |
llvm-svn: 202639
|
| |
|
|
| |
llvm-svn: 202625
|
| |
|
|
|
|
| |
within an extern "C" block in C++ code.
llvm-svn: 202615
|
| |
|
|
| |
llvm-svn: 202611
|
| |
|
|
| |
llvm-svn: 202595
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Was r202442
There were two issues with the original patch that have now been fixed.
1. We were memset'ing over a FileEntry in a test case. After adding a
std::string to FileEntry, this still happened to not break for me.
2. I didn't pass the FileManager into the new compiler instance in
compileModule. This was hidden in some cases by the fact I didn't
clear the module cache in the test.
Also, I changed the copy constructor for FileEntry, which was memcpy'ing
in a (now) unsafe way.
llvm-svn: 202539
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A 'remark' is information that is not an error or a warning, but rather some
additional information provided to the user. In contrast to a 'note' a 'remark'
is an independent diagnostic, whereas a 'note' always depends on another
diagnostic.
A typical use case for remark nodes is information provided to the user, e.g.
information provided by the vectorizer about loops that have been vectorized.
This patch provides the initial implementation of 'remarks'. It includes the
actual definiton of the remark nodes, their printing as well as basic parameter
handling. We are reusing the existing diagnostic parameters which means a remark
can be enabled with normal '-Wdiagnostic-name' flags and can be upgraded to
an error using '-Werror=diagnostic-name'. '-Werror' alone does not upgrade
remarks.
This patch is by intention minimal in terms of parameter handling. More
experience and more discussions will most likely lead to further enhancements
in the parameter handling.
llvm-svn: 202475
|
| |
|
|
|
|
| |
Revert r202442, which broke the buildbots.
llvm-svn: 202443
|
| |
|
|
|
|
|
|
| |
Pass through the externally-visible names that we got from the VFS down
to FileManager, and test that this is the name showing up in __FILE__,
diagnostics, and debug information.
llvm-svn: 202442
|
| |
|
|
|
|
|
| |
Keep the copy constructor around, and add a FIXME that we should really
remove it as soon as we have C++11 std::map's emplace function.
llvm-svn: 202439
|
| |
|
|
|
|
| |
This reverts commit r202420, which broke the build.
llvm-svn: 202421
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This cleans up some constructors that would not be safe once FileEntry
owns the storage for its name. These were already suspect, since they
wouldn't work if the FileEntry had an open file descriptor. The only
user for these constructors was in UniqueFileContainer, which wasn't a
very useful abstraction anyway. So it and UniqueDirContainer have been
replaced with std::map<UniqueID, *>.
This change should not affect anything outside the FileManager.
llvm-svn: 202420
|
| |
|
|
|
|
|
| |
This is a small bit of refactoring in preparation for FileEntry owning
the storage for its own name.
llvm-svn: 202412
|
| |
|
|
| |
llvm-svn: 202360
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When true, sets the name of the file to be the name from
'external-contents'. Otherwise, you get the virtual path that the file
was looked up by. This will not affect any non-virtual paths, or fully
virtual paths (for which there is no reasonable 'external' name anyway).
The setting is available globally, but can be overriden on a per-file
basis.
The goal is that this setting will control which path you see in debug
info, diagnostics, etc. which are sensitive to which path is used. That
will come in future patches that pass the name through to FileManager.
llvm-svn: 202329
|
| |
|
|
|
|
|
| |
-march which doesnt exist on sparc gcc to -mcpu. While here adjust a
few tests to not write an unused temporary file.
llvm-svn: 202177
|