Add a comment and a test to ~DiagnosticEngine about the ordering
requirements on the teardown of DiagnosticConsumer. This could also be
accomplished by rearranging the fields of ~DiagnosticEngine, but I felt
that this was a better, more explicit solution.
This fixes PR21911, an issue that occurred after the unique_ptr
migration in r222193.
llvm-svn: 224454
Summary:
Because GCC doesn't use $1 for code generation, inline assembly code can use $1 without having to add it to the clobbers list.
LLVM, on the other hand, does not shy away from using $1, and this can cause conflicts with inline assembly which assumes GCC-like code generation.
A solution to this problem is to make Clang automatically clobber $1 for all MIPS inline assembly.
This is not the optimal solution, but it seems like a necessary compromise, for now.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6638
llvm-svn: 224428
components. These sometimes get synthetically added, and we don't want -Ifoo
and -I./foo to be treated fundamentally differently here.
llvm-svn: 224055
This way, the step generating SVNVersion.inc gets rerun every time someone
changes GetSVN.cmake (which is the file that decides how the contents of
SVNVersion.inc look). This makes hacking on GetSVN.cmake a bit easier.
llvm-svn: 223861
basic microarchitecture names, and add support (with tests) for parsing
all of the masic microarchitecture names for CPUs documented to be
accepted by GCC with -march. I didn't go back through the 32-bit-only
old microarchitectures, but this at least brings the recent architecture
names up to speed. This is essentially the follow-up to the LLVM commit
r223769 which did similar cleanups for the LLVM CPUs.
One particular benefit is that you can now use -march=westmere in Clang
and get the LLVM westmere processor which is a different ISA variant (!)
and so quite significant.
Much like with r223769, I would appreciate the Intel folks carefully
thinking about the macros defined, names used, etc for the atom chips
and newest primary x86 chips. The current patterns seem quite strange to
me, especially here in Clang.
Note that I haven't replicated the per-microarchitecture macro defines
provided by GCC. I'm really opposed to source code using these rather
than using ISA feature macros.
llvm-svn: 223776
is for each machine. Fix up darwin tests that were testing for
aapcs on armv7-ios when the actual ABI is apcs.
Should be no user visible change without -cc1.
llvm-svn: 223429
Summary:
Allow CUDA host device functions with two code paths using __CUDA_ARCH__
to differentiate between code path being compiled.
For example:
__host__ __device__ void host_device_function(void) {
#ifdef __CUDA_ARCH__
device_only_function();
#else
host_only_function();
#endif
}
Patch by Jacques Pienaar.
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D6457
llvm-svn: 223271
Summary:
In particular, remove the defaults and reorder fields so it matches the result of DataLayout::getStringDescription().
Change by David Neto.
Reviewers: dschuff, sdt
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6482
llvm-svn: 223140
Summary:
This change implements warnings if macro name is identical to a keyword or
reserved identifier. The warnings are different depending on the "danger"
of the operation. Defining macro that replaces a keyword is on by default.
Other cases produce warning that is off by default but can be turned on
using option -Wreserved-id-macro.
This change fixes PR11488.
Reviewers: rnk
Reviewed By: rnk
Subscribers: rnk, cfe-commits
Differential Revision: http://reviews.llvm.org/D6194
llvm-svn: 223114
rather than trying to extract this information from the FileEntry after the
fact.
This has a number of beneficial effects. For instance, diagnostic messages for
failed module builds give a path relative to the "module root" rather than an
absolute file path, and the contents of the module includes file is no longer
dependent on what files the including TU happened to inspect prior to
triggering the module build.
llvm-svn: 223095
To support it in the frontend, the following has been added:
- generic address space type attribute;
- documentation for the OpenCL address space attributes;
- parsing of __generic(generic) keyword;
- test code for the parser and diagnostics.
llvm-svn: 222831
Summary:
This resolves [[ http://llvm.org/bugs/show_bug.cgi?id=17391 | PR17391 ]].
GCC's sources were used as a guide (couldn't find much information in ARM documentation).
Reviewers: doug.gregor, asl
Reviewed By: asl
Subscribers: asl, aemerson, cfe-commits
Differential Revision: http://reviews.llvm.org/D6339
llvm-svn: 222741
In order to keep SVNVersion.inc from being regenerated on every build, we need
to specify as a dependency a file that only changes when the VC state updates.
I previously just had .svn/entries, but that's only used by Subversion 1.6.
1.7 uses .svn/wc.db instead; prefer that if it's present.
(Thanks, Nico!)
llvm-svn: 222407
Now that LLVM's helper script GetSVN.cmake actually works consistently,
there's no reason not to use it. We avoid having to regenerate SVNVersion.inc
every time by marking it as dependent on Git's reflog or SVN's entries file.
This should end most of the issues of the AST format changing and breaking
old module files: CMake-Clang should now detect that the version changed just
like Autoconf-Clang has.
Based on r190557. Depends on LLVM r222391.
llvm-svn: 222393
Summary:
Make DiagnosticsEngine::takeClient return std::unique_ptr<>. Updated
callers to store conditional ownership using a pair of pointer and unique_ptr
instead of a pointer + bool. Updated code that temporarily registers clients to
use the non-owning registration (+ removed extra calls to takeClient).
Reviewers: dblaikie
Reviewed By: dblaikie
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6294
llvm-svn: 222193
Remove flag parsing details from the public header.
Use SanitizerSet to represent the set of enabled sanitizers.
Cleanup the implementation: update the comments to
reflect reality, remove dead code.
No functionality change.
llvm-svn: 221968
This option was misleading because it looked like it enabled the
language feature of SEH (__try / __except), when this option was really
controlling which EH personality function to use. Mingw only supports
SEH and SjLj EH on x86_64, so we can simply do away with this flag.
llvm-svn: 221963
Get rid of ugly SanitizerOptions class thrust into LangOptions:
* Make SanitizeAddressFieldPadding a regular language option,
and rely on default behavior to initialize/reset it.
* Make SanitizerBlacklistFile a regular member LangOptions.
* Introduce the helper class "SanitizerSet" to represent the
set of enabled sanitizers and make it a member of LangOptions.
It is exactly the entity we want to cache and modify in CodeGenFunction,
for instance. We'd also be able to reuse SanitizerSet in
CodeGenOptions for storing the set of recoverable sanitizers,
and in the Driver to represent the set of sanitizers
turned on/off by the commandline flags.
No functionality change.
llvm-svn: 221653
Use the bitmask to store the set of enabled sanitizers instead of a
bitfield. On the negative side, it makes syntax for querying the
set of enabled sanitizers a bit more clunky. On the positive side, we
will be able to use SanitizerKind to eventually implement the
new semantics for -fsanitize-recover= flag, that would allow us
to make some sanitizers recoverable, and some non-recoverable.
No functionality change.
llvm-svn: 221558
This CPU definition is redundant. The Cortex-A9 is defined as
supporting multiprocessing extensions. Remove references to this CPU.
This CPU was recently removed from LLVM. See http://reviews.llvm.org/D6057
Change-Id: I62ae7cc656fcae54fbaefc4b6976e77e694a8678
llvm-svn: 221458
This patch simplifies how default target features are set for AMD bdver2
and bdver1. In particular, method 'getDefaultFeatures' now implements a
fallthrough from case 'CK_BDVER2' to case 'CK_BDVER1'.
That is because 'bdver2' has the same features available in bdver1 plus
BMI, FMA, F16C and TBM.
This patch also adds missing checks for predefined macros in test
predefined-arch-macros.c. In the case of BTVER2, the test now also checks
for F16C, BMI and PCLMUL. In the case of BDVER3 and BDVER4, the test now
also checks for the presence of FSGSBASE.
Differential Revision: http://reviews.llvm.org/D6134
llvm-svn: 221449
The most complex aspect of the convention is the handling of homogeneous
vector and floating point aggregates. Reuse the homogeneous aggregate
classification code that we use on PPC64 and ARM for this.
This convention also has a C mangling, and we apparently implement that
in both Clang and LLVM.
Reviewed By: majnemer
Differential Revision: http://reviews.llvm.org/D6063
llvm-svn: 221006
Now that we have initial support for VSX, we can begin adding
intrinsics for programmer access to VSX instructions. This patch
performs the necessary enablement in the front end, and tests it by
implementing intrinsics for minimum and maximum using the vector
double data type.
The main change in the front end is to no longer disallow "vector" and
"double" in the same declaration (lib/Sema/DeclSpec.cpp), but "vector"
and "long double" must still be disallowed. The new intrinsics are
accessed via vec_max and vec_min with changes in
lib/Headers/altivec.h. Note that for v4f32, we already access
corresponding VMX builtins, but with VSX enabled we should use the
forms that allow all 64 vector registers.
The new built-ins are defined in include/clang/Basic/BuiltinsPPC.def.
I've added a new test in test/CodeGen/builtins-ppc-vsx.c that is
similar to, but much smaller than, builtins-ppc-altivec.c. This
allows us to test VSX IR generation without duplicating CHECK lines
for the existing bazillion Altivec tests.
Since vector double is now legal when VSX is available, I've modified
the error message, and changed where we test for it and for vector
long double, since the target machine isn't visible in the old place.
This serendipitously removed a not-pertinent warning about 'long'
being deprecated when used with 'vector', when "vector long double" is
encountered and we just want to issue an error. The existing tests
test/Parser/altivec.c and test/Parser/cxx-altivec.cpp have been
updated accordingly, and I've added test/Parser/vsx.c to verify that
"vector double" is now legitimate with VSX enabled.
There is a companion patch for LLVM.
llvm-svn: 220989
SanitizerOptions is not even a POD now, so having global variable of
this type, is not nice. Instead, provide a regular constructor and clear()
method, and let each CodeGenFunction has its own copy of SanitizerOptions
it uses.
llvm-svn: 220920
Wire it through everywhere we have support for fastcall, essentially.
This allows us to parse the MSVC "14" CTP headers, but we will
miscompile them because LLVM doesn't support __vectorcall yet.
Reviewed By: Aaron Ballman
Differential Revision: http://reviews.llvm.org/D5808
llvm-svn: 220573
This allows a module to specify that it logically contains a file, but that
said file is non-modular and intended for textual inclusion. This allows
layering checks to work properly in the presence of such files.
llvm-svn: 220448
When SanitizerBlacklist decides if the SourceLocation is blacklisted,
we need to first turn it into a SpellingLoc before fetching the filename
and scanning "src:" entries. Otherwise we will fail to fecth the
correct filename for function definitions coming from macro expansion.
llvm-svn: 220403
This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mode.
llvm-svn: 220244
This commit changes the way we blacklist global variables in ASan.
Now the global is excluded from instrumentation (either regular
bounds checking, or initialization-order checking) if:
1) Global is explicitly blacklisted by its mangled name.
This part is left unchanged.
2) SourceLocation of a global is in blacklisted source file.
This changes the old behavior, where instead of looking at the
SourceLocation of a variable we simply considered llvm::Module
identifier. This was wrong, as identifier may not correspond to
the file name, and we incorrectly disabled instrumentation
for globals coming from #include'd files.
3) Global is blacklisted by type.
Now we build the type of a global variable using Clang machinery
(QualType::getAsString()), instead of llvm::StructType::getName().
After this commit, the active users of ASan blacklist files
may have to revisit them (this is a backwards-incompatible change).
llvm-svn: 220097
This commit changes the way we blacklist functions in ASan, TSan,
MSan and UBSan. We used to treat function as "blacklisted"
and turned off instrumentation in it in two cases:
1) Function is explicitly blacklisted by its mangled name.
This part is not changed.
2) Function is located in llvm::Module, whose identifier is
contained in the list of blacklisted sources. This is completely
wrong, as llvm::Module may not correspond to the actual source
file function is defined in. Also, function can be defined in
a header, in which case user had to blacklist the .cpp file
this header was #include'd into, not the header itself.
Such functions could cause other problems - for instance, if the
header was included in multiple source files, compiled
separately and linked into a single executable, we could end up
with both instrumented and non-instrumented version of the same
function participating in the same link.
After this change we will make blacklisting decision based on
the SourceLocation of a function definition. If a function is
not explicitly defined in the source file, (for example, the
function is compiler-generated and responsible for
initialization/destruction of a global variable), then it will
be blacklisted if the corresponding global variable is defined
in blacklisted source file, and will be instrumented otherwise.
After this commit, the active users of blacklist files may have
to revisit them. This is a backwards-incompatible change, but
I don't think it's possible or makes sense to support the
old incorrect behavior.
I plan to make similar change for blacklisting GlobalVariables
(which is ASan-specific).
llvm-svn: 219997
Summary:
The general approach is to add extra paddings after every field
in AST/RecordLayoutBuilder.cpp, then add code to CTORs/DTORs that poisons the paddings
(CodeGen/CGClass.cpp).
Everything is done under the flag -fsanitize-address-field-padding.
The blacklist file (-fsanitize-blacklist) allows to avoid the transformation
for given classes or source files.
See also https://code.google.com/p/address-sanitizer/wiki/IntraObjectOverflow
Test Plan: run SPEC2006 and some of the Chromium tests with -fsanitize-address-field-padding
Reviewers: samsonov, rnk, rsmith
Reviewed By: rsmith
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D5687
llvm-svn: 219961
The final goal is to get rid of all the rest overloads that
accept LLVM objects (llvm::Function and llvm::GlobalVariable),
and pass in source-level entities instead.
llvm-svn: 219937
Soon we'll need to have access to blacklist before the CodeGen
phase (see http://reviews.llvm.org/D5687), so parse and construct
the blacklist earlier.
llvm-svn: 219857
This change moves SanitizerBlacklist.h from lib/CodeGen
to public Clang headers in include/clang/Basic. SanitizerBlacklist
is currently only used in CodeGen to decide which functions/modules
should be instrumented, but this will soon change as ASan will
optionally modify class layouts during AST construction
(http://reviews.llvm.org/D5687). We need blacklist machinery
to be available at this point.
llvm-svn: 219840
Thumb1 has legitimate reasons for preferring 32-bit alignment of types
i1/i8/i16, since the 16-bit encoding of "add rD, sp, #imm" requires #imm to be
a multiple of 4. However, this is a trade-off betweem code size and RAM usage;
the DataLayout string is not the best place to represent it even if desired.
So this patch removes the extra Thumb requirements, hopefully making ARM and
Thumb completely compatible in this respect.
llvm-svn: 219735
Before, ARM and Thumb mode code had different preferred alignments, which could
lead to some rather unexpected results. There's justification for reducing it
from the default 64-bits (wasted space), but I don't think there is for going
below 32-bits.
There's no actual ABI change here, just to reassure people.
llvm-svn: 219720
The current VSX feature for PowerPC specifies availability of the VSX
instructions added with the 2.06 architecture version. With 2.07, the
architecture adds new instructions to both the Category:Vector and
Category:VSX instruction sets. Additionally, unaligned vector storage
operations have improved performance.
This patch adds a feature to provide access to the new instructions
and performance capabilities of Power8. For compatibility with GCC,
the feature is controlled via a new -mpower8-vector switch, and the
feature causes the __POWER8_VECTOR__ builtin define to be generated by
the preprocessor.
There is a companion patch for llvm being committed at the same time.
llvm-svn: 219502
Includes parsing and semantic analysis for 'omp teams' directive support from OpenMP 4.0. Adds additional analysis to 'omp target' directive with 'omp teams' directive.
llvm-svn: 219385
Includes parsing and semantic analysis for 'omp teams' directive support from OpenMP 4.0. Adds additional analysis to 'omp target' directive with 'omp teams' directive.
llvm-svn: 219197
in availability attribute by preserving this info.
in VersionTuple and using it in pretty printing of attributes
and yet using '.' as separator when diagnosing unavailable
message calls. rdar://18490958
llvm-svn: 219124
The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and
FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be
modeled using the same target feature, and all double-precision
operations are already disabled by the fp-only-sp target features.
llvm-svn: 218748
The ARM ACLE describes the values as hex constants rather than numeric
constants; follow suit. Address post-commit review comments from Jon Roelofs.
llvm-svn: 218009
Extend ARM ACLE support (Section 6.5.1) for AArch32. Define __ARM_FP if
hardware floating point support is available as per the value defined by the
ACLE.
llvm-svn: 217957
Summary:
le64 is a generic little-endian 64-bit processor, mimicking le32.
Also see the associated LLVM change.
Test Plan: make check-all
Reviewers: dschuff
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5318
llvm-svn: 217694
off by default, issue a warning if %s directive is used in
certain CF/NS formatting APIs, to assist user in deprecating
use of such %s in these APIs. rdar://18182443
llvm-svn: 217467
Because we may change the name of a FileEntry inside getFile, the name
returned by FileEntry::getName() could be destroyed. This was causing a
use-after-free when searching the HeaderFileInfo on-disk hashtable for a
module or pch.
llvm-svn: 217385
This warning is basically useless because the "previous versions" being referred to is MSVC 2005 and earlier, and we obviously do not care about them. However, this warning isn't particularly chatty (I don't recall ever seeing it previously), and it has the opportunity to point out cases where the cv-qualifiers differ unintentionally (like this case), so I am leaving it enabled for now.
llvm-svn: 216267
variable that has regiser constraint "r" is not 64-bit.
General register operands are output using 64-bit "x" register names, regardless
of the size of the variable, unless the asm operand is prefixed with the "%w"
modifier. This surprises and confuses many users who aren't familiar with
aarch64 inline assembly rules.
With this commit, a note and fixit hint are printed which tell the users that
they need modifier "%w" in order to output a "w" register instead of an "x"
register.
<rdar://problem/12764785>
llvm-svn: 216260
Name might be empty again after we removed the '%' prefix
and Name[0] would assert.
Found on code like
register int foo asm("%" MACRO);
where MACRO was supposed to be defined in a header file that was not found.
llvm-svn: 215834
With modules we start accessing headers for the first time while reading
the module map, which often has very different paths from the include
scanning logic.
Using the name by which the file was accessed gets us one step closer to
the right solution, which is using a FileName abstraction that decouples
the name by which a file was accessed from the FileEntry.
llvm-svn: 215541
And in the process, discover that FileManager::removeStatCache had a
double-delete when removing an element from the middle of the list (at
the beginning or the end of the list, there was no problem) and add a
unit test to exercise the code path (which successfully crashed when run
(with modifications to match the old API) without this patch applied)
llvm-svn: 215388
class Module. It's almost always going to be the same as
getContainingModule() for top-level modules, so just add a map to cover
the remaining cases. This lets us do less bookkeeping to keep the
ModuleMap fields up to date.
llvm-svn: 215268
The previous encoding only allowed a single digit for the minor version
number. This changes it to use 2 digits for both the minor version and the
revision number.
llvm-svn: 215245
intent when we added remark support, but was never implemented in the general
case, because the first -R flags didn't need it. (-Rpass= had special handling
to accomodate its argument.)
-Rno-foo, -Reverything, and -Rno-everything can be used to turn off a remark,
or to turn on or off all remarks. Per discussion on cfe-commits, -Weverything
does not affect remarks, and -Reverything does not affect warnings or errors.
The only "real" -R flag we have right now is -Rmodule-build; that flag is
effectively renamed from -Wmodule-build to -Rmodule-build by this change.
-Wpass and -Wno-pass (and their friends) are also renamed to -Rpass and
-Rno-pass by this change; it's not completely clear whether we intended to have
a -Rpass (with no =pattern), but that is unchanged by this commit, other than
the flag name. The default pattern is effectively one which matches no passes.
In future, we may want to make the default pattern be .*, so that -Reverything
works for -Rpass properly.
llvm-svn: 215046
Embedded systems seem to have inherited Darwin's choise of "unsigned long" for
size_t (via a bunch of headers), so we should respect that.
rdar://problem/17872787
llvm-svn: 214854
Summary:
Adding __int128 support explicitly for x86_64 because currently it's on
only when pointer size >= 64 which is not the case for x32.
Test Plan: One of the tests using __int128 is updated
Reviewers: atanasyan, chandlerc
Subscribers: cfe-commits, rob.khasanov, zinovy.nis, dschuff
Differential Revision: http://reviews.llvm.org/D4755
llvm-svn: 214710
this pointer is always non-null. If the this pointer is null, it is undefined
and the compiler may optimize it away by assuming it is non-null. The null
checks are pushed into the callers.
llvm-svn: 214471
a) add SKX support to Clang driver;
b) add tests for SKX target and AVX512BW, AVX512DQ, AVX512VL features into clang driver tests
Patch by Zinovy Nis <zinovy.y.nis@intel.com>
llvm-svn: 214306
char-based types from "char" to "signed char". Adjust stdint.h to use
__INTx_TYPE__ directly without prefixing it with signed and to use
__UINTx_TYPE__ for unsigned ones.
The value of __INTx_TYPE__ now matches GCC.
llvm-svn: 214119
While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently
hard-coded via the target triple: powerpc64-linux is always ELFv1, while
powerpc64le-linux is always ELFv2.
These are of course the most common scenarios, but in principle it is
possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on
little-endian systems (and GCC does support that), and there are some
special use cases for that (e.g. certain Linux kernel versions could
only be built using ELFv1 on LE).
This patch implements the Clang side of supporting this, based on the
LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2
select the desired ABI if present. (If not, Clang uses the same default
rules as now.)
Specifically, the patch implements the following changes based on the
presence of the -mabi= option:
In the driver:
- Pass the appropiate -target-abi flag to the back-end
- Select the correct dynamic loader version (/lib64/ld64.so.[12])
In the preprocessor:
- Define _CALL_ELF to the appropriate value (1 or 2)
In the compiler back-end:
- Select the correct ABI in TargetInfo.cpp
- Select the desired ABI for LLVM via feature (elfv1/elfv2)
llvm-svn: 214074
Specifically the part where we removed a warning to be compatible with GCC, which has been widely regarded as a bad idea.
I'm not quite happy with how obtuse this warning is, especially in the fairly common case of a 32-bit integer literal, so I've got another patch awaiting review that adds a fixit to reduce confusion.
llvm-svn: 213935
This flag specifies that we are building an implementation file of the
module <name>, preventing importing <name> as a module. This does not
consider this to be the 'current module' for the purposes of doing
modular checks like decluse or non-modular-include warnings, unlike
-fmodule-name.
This is needed as a stopgap until:
1) we can resolve relative includes to a VFS-mapped module (or can
safely import a header textually and as part of a module)
and ideally
2) we can safely do incremental rebuilding when implementation files
import submodules.
llvm-svn: 213767
The main subtlety here is that the Darwin tools still need to be given "-arch
arm64" rather than "-arch aarch64". Fortunately this already goes via a custom
function to handle weird edge-cases in other architectures, and it tested.
I removed a few arm64_be tests because that really isn't an interesting thing
to worry about. No-one using big-endian is also referring to the target as
arm64 (at least as far as toolchains go). Mostly they date from when arm64 was
a separate target and we *did* need a parallel name simply to test it at all.
Now aarch64_be is sufficient.
llvm-svn: 213744
It's also possible to just write "= nullptr", but there's some question
of whether that's as readable, so I leave it up to authors to pick which
they prefer for now. If we want to discuss standardizing on one or the
other, we can do that at some point in the future.
llvm-svn: 213439
1. Revert "Add default feature for CPUs on AArch64 target in Clang"
at r210625. Then, all enabled feature will by passed explicitly by
-target-feature in -cc1 option.
2. Get "-mfpu" deprecated.
3. Implement support of "-march". Usage is:
-march=armv8-a+[no]feature
For instance, "-march=armv8-a+neon+crc+nocrypto". Here "armv8-a" is
necessary, and CPU names are not acceptable. Candidate features are
fp, neon, crc and crypto. Where conflicting feature modifiers are
specified, the right-most feature is used.
4. Implement support of "-mtune". Usage is:
-march=CPU_NAME
For instance, "-march=cortex-a57". This option will ONLY get
micro-architectural feature enabled specifying to target CPU,
like "+zcm" and "+zcz" for cyclone. Any architectural features
WON'T be modified.
5. Change usage of "-mcpu" to "-mcpu=CPU_NAME+[no]feature", which is
an alias to "-march={feature of CPU_NAME}+[no]feature" and
"-mtune=CPU_NAME" together. Where this option is used in conjunction
with -march or -mtune, those options take precedence over the
appropriate part of this option.
llvm-svn: 213353
constants. Comparing int against a constant of the given type like
UINT8_MAX will otherwise force a promotion to unsigned int, which is
typically not expected.
llvm-svn: 213301
This restores the original behaviour of -fmsc-version. The older option
remains as a mechanism for specifying the basic version information. A
secondary option, -fms-compatibility-version permits the user to specify an
extended version to the driver.
The new version takes the value as a dot-separated value rather than the
major * 100 + minor format that -fmsc-version format. This makes it easier to
specify the value as well as a more flexible manner for specifying the value.
Specifying both values is considered an error.
The older parameter is left solely as a driver option, which is normalised into
the newer parameter. This allows us to retain a single code path in the
compiler itself whilst preserving the semantics of the old parameter as well as
avoid having to determine which of two formats are being used by the invocation.
The test changes are due to the fact that the compiler no longer supports the
old option, and is a direct conversion to the new option.
llvm-svn: 213119
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
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
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
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
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
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
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
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
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
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
This reverts commit r211096. Looks like it broke the msvc build:
SemaOpenMP.cpp(140) : error C4519: default template arguments are only allowed on a class template
llvm-svn: 211113
By describing system header suppressions directly in tablegen we eliminate
special cases in getDiagnosticSeverity().
Dropping the reliance on builtin diagnostic classes when mapping also gets us
closer to the goal of reusing the diagnostic machinery for custom diagnostics.
No change in functionality.
llvm-svn: 211023
This improves conformance with ACLE 6.4.1. Define additional macros that
indicate support for the ARM and Thumb instruction set architecture. This
includes the following set of macros:
__ARM_ARCH
__ARM_ARCH_ISA_ARM
__ARM_ARCH_ISA_THUMB
__ARM_32BIT_STATE
These help identify the environment that the code is intended to execute on.
Adjust the handling for ACLE 6.4.2 to be more correct. We would define the
profile as a free-standing token rather than a quoted single character.
llvm-svn: 210991
Thanks to David Blakie and Richard Smith for pointing out that we can retain the
-Wswitch coverage while avoiding the warning from GCC by pushing the unreachable
outside of the switch!
llvm-svn: 210812
tools/clang/lib/Basic/DiagnosticIDs.cpp: In function ‘clang::DiagnosticIDs::Level toLevel(clang::diag::Severity)’:
tools/clang/lib/Basic/DiagnosticIDs.cpp:382:1: warning: control reaches end of non-void function [-Wreturn-type]
tools/clang/lib/Format/Format.cpp: In member function ‘virtual std::string clang::format::ParseErrorCategory::message(int) const’:
tools/clang/lib/Format/Format.cpp:282:1: warning: control reaches end of non-void function [-Wreturn-type]
Add a default cases that asserts that we handle the severity, parse error.
llvm-svn: 210804
This begins to address cognitive dissonance caused by treating the Note
diagnostic level as a severity in the diagnostic engine.
No change in functionality.
llvm-svn: 210758
For ARM target, we can use CRYPTO and CRC features if we select
cortex-a57 by '-mcpu', but for AArch64 target, it doesn't work
unless adding with '-mfpu=crypto-neon-fp-armv8'. To keep consistency
between front-end and back-end and get end-users more easier to use,
we'd better add default feature for CPUs on AArch64 target as well.
llvm-svn: 210625
Diagnostic mappings are used to calculate the final severity of diagnostic
instances.
Detangle the implementation to reflect the terminology used in documentation
and bindings.
No change in functionality.
llvm-svn: 210518
Anyone enabling this warning would expect to hear about all occurrences
including those in system headers that can cause non-reproducible builds.
To achieve this, rework ShowInSystemHeader to remove broken unused mapping code
that didn't make sense with a simpler and correct scheme.
llvm-svn: 210512
We probably just need to touch LLVM's configure this time to work around the
totally inadequate Makefile build server integration.
This reverts commit r210314.
llvm-svn: 210320
This will unbreak clang vendor builds as a follow-up to r210238, now that we
can't poke into LLVM's private config.h (nor should the string be exposed by
llvm-config.h).
This hopefully removes for good the last include of LLVM's config.h.
llvm-svn: 210313
Summary: The Linux Kernel is one example of a piece of software that relies on them.
Reviewers: atanasyan
Reviewed By: atanasyan
Differential Revision: http://reviews.llvm.org/D3756
llvm-svn: 210270
This corrects long-standing misuses of LLVM's internal config.h.
In most cases the public llvm-config.h header was intended and we can now
remove the old hacks thanks to LLVM r210144.
The config.h header is private, won't be installed and should no longer be
included by clang or other modules.
llvm-svn: 210145
There shouldn't be any difference in behaviour here, at least not in
any configurations people care about and possibly not in any reachable
configurations.
llvm-svn: 209899
A few (mostly CodeGen) parts of Clang were tightly coupled to the
AArch64 backend. Now that it's gone, they will not even compile.
I've also deduplicated RUN lines in many of the AArch64 tests. This
might improve "make check-all" time noticably: some of those NEON
tests were monsters.
llvm-svn: 209578
If we lookup a path using its 'real' path first, we need to ensure that
when we run header search we still use the VFS-mapped path or we will
not be able to find the corresponding module for the header.
The real problem is that we tie the name of a file to its underlying
FileEntry, which is uniqued by inode, so we only ever get the first name
it is looked up by. This doesn't work with modules, which rely on a
specific file system structure. I'm hoping to have time to write up a
proposal for fixing this more permanently soon, but as a stopgap this
patch updates the name of the file's directory if it comes from a VFS
mapping.
llvm-svn: 209534
Summary:
The limits on the number of fix-it hints and ranges attached to a
diagnostic are arbitrary and don't apply universally to all users of the
DiagnosticsEngine. The way the limits are enforced may lead to diagnostics
generating invalid sets of fixes. I suggest removing the limits, which will also
simplify the implementation.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D3879
llvm-svn: 209468
There are a couple of issues with writing VFS maps that are awkward to
fix within the current mutually recursive approach. Instead, replace
the algorithm with an iterative version that uses an explicit stack of
directories.
Includes tests for cases the old approach was tripping on.
llvm-svn: 209332
Checking if a path starts with another path isn't sufficient for
determining if one is contained within the heirarchy of the other.
We need to ensure that the substring ends at a directory boundary.
llvm-svn: 209250
This moves the logic to write a JSON VFS mapping from the C api into
VirtualFileSystem, so that we can use it internally.
No functional change.
llvm-svn: 209241
Reid Kleckner