Key changes:
- Correctly (well ...) distinguish function declarations and variable
declarations with ()-initialization.
- Don't indent when breaking function declarations/definitions after the
return type.
- Indent variable declarations and typedefs when breaking after the
type.
This fixes llvm.org/PR17999.
llvm-svn: 212591
This flag is set by most other tools and avoids extra stat() calls. The
frontend will diagnose anyway as it performs the check atomically while opening
files at point of use.
We could probably make Driver::CheckInputsExist default to false and only
enable it in the main 'clang' binary, or even better only perform the checks if
we know the tool is external but that needs more thought.
llvm-svn: 212585
If we want to resolve the remaining FIXMEs here, we probably want to
extend the main lookup mechanism to perform lookup into dependent bases,
but we would have to tread lightly. Adding more name lookup has major
impact on compile time.
If we did extend the main mechanism, we would add a flag to LookupResult
that allows us to find names from dependent base classes where the base
is a specialization of a known template. The final LookupResult would
still return LookupResult::NotFoundInCurrentInstantiation, but it would
have a collection of Decls. If we find a real lookup result, we would
clear the flag and the existing lookup results and begin accumulating
only real lookup results.
We would structure the lookup as a secondary lookup between normal
lookup and typo correction for normal compilation, but for MSVC
compatibility mode, we would always enable this extra lookup into
dependent bases.
llvm-svn: 212566
This merges the two tests into one since there is no real reason to separate
them. It also fixes the test invocation to specify -fms-compatibility without
which we would end up without an Intrin.h header.
llvm-svn: 212563
MSVC appears to perform name lookup into dependent base classes when the
dependent base class has a known primary template. This allows them to
know whether some unqualified ids are types or not, which allows them to
parse more class templates without typename keywords.
We can do the same thing when type name lookup fails, and if we find a
single type decl in one of our dependent base classes, recover as though
the user wrote 'typename MyClass::TypeFromBase'.
This allows us to parse some COM smart pointer classes in wrl/client.h
from the Windows 8 SDK.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D4237
llvm-svn: 212561
Also provide _setjmpex(). r200243 put in _setjmp() and _setjmpex() behind a
comment since jmp_buf wasn't available. r200344 added jmp_buf and put in
_setjmp(), but missed _setjmpex().
llvm-svn: 212557
r184166 added an X86_32 function in the middle of the SystemZ code.
The SystemZ port had been added only a couple of weeks earlier and
the original patch probably predated that.
No behavioral change intended.
llvm-svn: 212524
Protect MMX specific declarations under a __MMX__ guard. This header can be
included on non-x86 architectures (e.g. ARM) which do not support the MMX ISA.
Use the preprocessor to prevent these declarations from being processed.
llvm-svn: 212512
Although the functions are marked as always_inline, the compiler with which they
are used may not honour the extended attributes and emit them as functions. In
such a case, indicate that they should have extern "C" linkage and should not be
mangled in C++ style if used within C++.
llvm-svn: 212511
Of course, such code is horribly broken and will explode on impact.
That said, ATL does it, and we have to support them, at least a little
bit.
Fixes PR20191.
llvm-svn: 212508
All blacklisting logic is now moved to the frontend (Clang).
If a function (or source file it is in) is blacklisted, it doesn't
get sanitize_address attribute and is therefore not instrumented.
If a global variable (or source file it is in) is blacklisted, it is
reported to be blacklisted by the entry in llvm.asan.globals metadata,
and is not modified by the instrumentation.
The latter may lead to certain false positives - not all the globals
created by Clang are described in llvm.asan.globals metadata (e.g,
RTTI descriptors are not), so we may start reporting errors on them
even if "module" they appear in is blacklisted. We assume it's fine
to take such risk:
1) errors on these globals are rare and usually indicate wild memory access
2) we can lazily add descriptors for these globals into llvm.asan.globals
lazily.
llvm-svn: 212505
Now CodeGenFunction is responsible for looking at sanitizer blacklist
(in CodeGenFunction::StartFunction) and turning off instrumentation,
if necessary.
No functionality change.
llvm-svn: 212501
Get rid of cached CodeGenModule::SanOpts, which was used to turn off
sanitizer codegen options if current LLVM Module is blacklisted, and use
plain LangOpts.Sanitize instead.
1) Some codegen decisions (turning TBAA or writable strings on/off)
shouldn't depend on the contents of blacklist.
2) llvm.asan.globals should *always* be created, even if the module
is blacklisted - soon Clang's CodeGen where we read sanitizer
blacklist files, so we should properly report which globals are
blacklisted to the backend.
llvm-svn: 212499
r212427 formalized the message-passing pattern by making these argument
structures const. This commit changes output arguments to get passed by
reference so we can eliminate mutable fields.
llvm-svn: 212497
Assertion failures call abort(), which return an exit code of 3 on
Windows. The 'not' utility has the same check.
Unfortunately, the crash-report.c test requires a shell, so it does not
run for me locally, so I can only test this manually.
There's still more work to be done here: we should generate a batch
script instead of a shell script on Windows.
llvm-svn: 212481
I misidentified the problem and did not test suffifiently. The files had
correctly been removed, but for some reason they still remained in my git
checkout. Not adding the files back to CMakeLists.txt, but rather removing
the stale files was the solution. Sorry for the unnecessary noise.
llvm-svn: 212446
The MS ABI RTTI emission code would choose names for IR types like
%"MSRTTITypeDescriptor\02". This name is undesirable because it
requires escaping; the underlying reason for this is that the name is
unprintable. Fix this by naming it %rtti.TypeDescriptor2.
While here, stop trying to do lookups in the LLVM Module's type table.
Instead, store the IR types in MicrosoftCXXABI. Lookups by name aren't
particularly fast.
llvm-svn: 212439
Let's not expose ABI specific minutia inside of CodeGenModule and Type.
Instead, let's abstract it through CXXABI.
This gets rid of:
CodeGenModule::getCompleteObjectLocator,
CodeGenModule::EmitFundamentalTypeDescriptor{s,},
CodeGenModule::getMSTypeDescriptor,
CodeGenModule::getMSCompleteObjectLocator,
CGCXXABI::shouldRTTIBeUnique,
CGCXXABI::classifyRTTIUniqueness.
CGRTTI was *almost* entirely centered around providing Itanium-style
RTTI information. Instead of providing interfaces that only it
consumes, move it to the ItaniumCXXABI implementation file. This allows
it to have access to Itanium-specific implementation details without
providing useless expansion points for the Microsoft ABI side.
Differential Revision: http://reviews.llvm.org/D4261
llvm-svn: 212435
These two functions initialize the source manager and header search objects and
shouldn't be in InitPreprocessor which is concerned with priming the
preprocessor itself and predefining macros.
llvm-svn: 212434
Consolidate CXUnsavedFile argument handling in API functions to support a wider
cleanup of various file remapping schemes in the frontend.
llvm-svn: 212427
StmtDumper.cpp is called ASTDumper.cpp these days, and usually works well
for new AST nodes without changes. There's now DataRecursiveASTVisitor
in addition to RecursiveASTVisitor, and serialization wasn't mentioned.
llvm-svn: 212426
Give scope a SEHTryScope bit, set that in ParseSEHTry(), and let Sema
walk the scope chain to find the SEHTry parent on __leave statements.
(They are rare enough that it seems better to do the walk instead of
giving Scope a SEHTryParent pointer -- this is similar to AtCatchScope.)
llvm-svn: 212422
Summary:
This gives us back the test coverage we lost when I made
MicrosoftExtensions.c x86-only.
Reviewers: majnemer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4401
llvm-svn: 212414
Although these aren't strictly related to LLVM's core threading, it's
reasonable to avoid pthread usage in clang when building with
LLVM_ENABLE_THREADS disabled.
llvm-svn: 212395
Handle 'remark' level diagnostics as warnings instead of supplemental notes,
and use a covered switch to ensure the mapping is kept up to date.
llvm-svn: 212385
This adds support for simple MSVC compatibility mode intrinsics. These
intrinsics are simple in that they are either directly passed through to the
annotated MSBuiltin intrinsic or they mirror existing GCC builtins.
llvm-svn: 212378
This completes the infrastructure for the new MSBuiltin aliases in the
instruction definitions. These behave similar to the GCCBuiltin in that they
can be implicitly constructed without special handling unless needed.
With this change it is possible to annotate an LLVM intrinsic in the backend
instruction definitions and indicate it as a builtin in the Builtin*.def files
in clang via LANGBUILTIN. That will automatically pass through the instruction
much as a GCCBuiltin.
Note that there is no need for the special handling for ensuring that the
compatibility flag is enabled since the filtering on the LANGBUILTIN will
automatically prevent the intrinsic from bleeding into non-MS compatible
compiler invocations.
llvm-svn: 212359
Summary:
Because a global created by GetOrCreateLLVMGlobal() is not finalised until later viz:
extern char a[];
char f(){ return a[5];}
char a[10];
Change MangledDeclNames to use a MapVector rather than a DenseMap so that the
Metadata is output in order of original declaration, so to make deterministic
and improve human readablity.
Differential Revision: http://reviews.llvm.org/D4176
llvm-svn: 212263
The Itanium rules are not appropriate for the MS ABI. RTTI data is
_never_ imported and thus is never available_externally. It is either
internal (if the type's linkage is internal) or linkonce_odr.
This also means that classes which inherit from dllimport'd bases force
their translation unit to duplicate the entirety of the RTTI data of
that base.
Interestingly, the complete object locator can never be referenced by
translation units which import the class.
This fixes PR20106.
llvm-svn: 212256
This corrects SVN r212196's naming change to use the proper prefix of
`__builtin_arm_` instead of `__builtin_`.
Thanks to Yi Kong for pointing out the incorrect naming!
llvm-svn: 212253
Also, forgot to say in the commit message of r212238: Library authors will
see a warning about this issue if they build with -Wsystem-headers.
llvm-svn: 212243
r210091 made initialization checking more strict in c++11 mode. LWG2193 is
about changing standard libraries to still be valid under these new rules,
but older libstdc++ (e.g. libstdc++4.6 in -D_GLIBCXX_DEBUG=1 mode, or stlport)
do not implement that yet. So fall back to the C++03 semantics for container
classes in system headers below the std namespace.
llvm-svn: 212238
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
It hasn't been updated to reflect the progress we've made. We've fuzz
tested VFTables, VBTables, layout, and RTTI data. We support lambdas
that are compatible with their scheme.
llvm-svn: 212193
Recent enhancements in the diagnostics engine mean that
TransformActions::report() no longer needs to duplicate this suppression logic.
That's great because the old code was flawed and would have attached notes to
the wrong primary diagnostic in non-trivial use.
With these changes it becomes safe to use reportNote() freely in the migration
tool.
llvm-svn: 212191
See https://code.google.com/p/address-sanitizer/issues/detail?id=299 for the
original feature request.
Introduce llvm.asan.globals metadata, which Clang (or any other frontend)
may use to report extra information about global variables to ASan
instrumentation pass in the backend. This metadata replaces
llvm.asan.dynamically_initialized_globals that was used to detect init-order
bugs. llvm.asan.globals contains the following data for each global:
1) source location (file/line/column info);
2) whether it is dynamically initialized;
3) whether it is blacklisted (shouldn't be instrumented).
Source location data is then emitted in the binary and can be picked up
by ASan runtime in case it needs to print error report involving some global.
For example:
0x... is located 4 bytes to the right of global variable 'C::array' defined in '/path/to/file:17:8' (0x...) of size 40
These source locations are printed even if the binary doesn't have any
debug info.
This is an ABI-breaking change. ASan initialization is renamed to
__asan_init_v4(). Pre-built libraries compiled with older Clang will not work
with the fresh runtime.
llvm-svn: 212188
defined or defined identically before there will not be any
change in functionality.
MinGW-w64 defines __GNUC_VA_LIST as
#define __GNUC_VA_LIST
which is different than the definition here, causing
a warning without the guard.
llvm-svn: 212183
Summary:
This patch adds minimal coverage for each -mcpu value to ensure that none of them can pass an empty string in -mabi.
Prior to r212176, many -mcpu values would trigger this.
Differential Revision: http://reviews.llvm.org/D4272
llvm-svn: 212182
Summary:
For example: s/MIPS32-EB-AS/MIPS32R2-EB-AS/ since it is for MIPS32r2 not MIPS32.
This reduces the noise in my next Clang patch.
Differential Revision: http://reviews.llvm.org/D4271
llvm-svn: 212177
ARMv8 adds (to both AArch32 and AArch64) acquiring and releasing
variants of the exclusive operations, in line with the C++11 memory
model.
This adds support for two new intrinsics to expose them to C & C++
developers directly: __builtin_arm_ldaex and __builtin_arm_stlex, in
direct analogy with the versions with no implicit barrier.
rdar://problem/15885451
llvm-svn: 212175
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
C++ [basic.start.main]p1: "It shall have a return type of type int"
ISO C is also clear about this, so only accept 'int' with qualifiers in GNUMode
C.
llvm-svn: 212171
Fixes PR20110, where Clang hits an assertion failure when it expects that the
sub-expression of a bit cast to pointer to also be a pointer, but gets a value
instead.
Differential Revision: http://reviews.llvm.org/D4280
llvm-svn: 212160
This source range is useful for all kinds of diagnostic QOI and refactoring
work, so let's make it more discoverable.
This commit also makes use of the new function to enhance various diagnostics
relating to return types and resolves an old FIXME.
llvm-svn: 212154
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
LLVM r211399 started emitting .pdata for win64 by default.
Unfortunately, it produces invalid object files. I plan to fix that
Soon. For now, don't request unwind tables. This fixes the clang-cl
self-host on win64.
llvm-svn: 212137
The pointer for a class's RTTI data comes right before the VFTable but
has no name. To be properly compatible with this, we do the following:
* Create a single GlobalVariable which holds the contents of the VFTable
_and_ the pointer to the RTTI data.
* Create a GlobalAlias, with appropriate linkage/visibility, that points
just after the RTTI data pointer. This ensures that the VFTable
symbol will always refer to VFTable data.
* Create a Comdat with a "Largest" SelectionKind and stick the private
GlobalVariable in it. By transitivity, the GlobalAlias will be a
member of the Comdat group. Using "Largest" ensures that foreign
definitions without an RTTI data pointer will _not_ be chosen in the
final linked image.
Whether or not we emit RTTI data depends on several things:
* The -fno-rtti flag implies that we should never not emit a pointer to
RTTI data before the VFTable.
* __declspec(dllimport) brings in the VFTable from a remote DLL. Use an
available_externally GlobalVariable to provide a local definition of
the VFTable. This means that we won't have any available_externally
definitions of things like complete object locators. This is
acceptable because they are never directly referenced.
To my knowledge, this completes the implementation of MSVC RTTI code
generation.
Further semantic work should be done to properly support /GR-.
llvm-svn: 212125
These flags enable behavior in MSVC that Clang has by default.
/Zc:inline essentially marks all COMDATs as discardable. In LLVM
parlance, this means using linkonce_odr linkage, which is what we
already do.
llvm-svn: 212117
Currently, we fail with an error.
Reviewers: rafael
Reviewed By: rafael
Subscribers: rnk, cfe-commits
Differential Revision: http://reviews.llvm.org/D4347
llvm-svn: 212110
This patch removes the dead code, and refines the
getEHResumeBlock() slightly.
The CleanupHackLevel was a hack to the old exception
handling intrinsics, which have several issues with function
inliner.
Since LLVM 3.0, the new landingpad and resume instructions
are added to LLVM IR. With the new exception handling
mechanism, most of the issues are fixed now. We should
always use these instructions to implement the exception
handling code nowadays, and we don't need the hack any more.
Besides, the `CleanupHackLevel` is a compile-time constant,
thus other cases have been considered as dead code for a while.
llvm-svn: 212097
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
In 32b mode the reference count for block addresses
is not zero. This prevents inlining and constant
folding and causes the test to fail. Changing
the triple allows runnning the test in 64b mode.
The array in foo2 is now local instead of static until
at lower optimization levels the interprocedural constant
propagator is invoked before the global optimizer.
llvm-svn: 212092
llvm r212077 causes this test to fail. We need to reorder some passes and
possibly make other changes to reenable the optimization being tested here.
llvm-svn: 212091
Update the strategy in r212083 to try JIT first and otherwise fall back to the
interpreter. This gives the best of both worlds and still builds fine with no
targets enabled.
Requires supporting changes from LLVM r212086.
llvm-svn: 212087
Fix the build when no targets are enabled. This dependency is incurred by two
unfortunate entries in LinkAllPasses.h included from cc1_main.cpp:
llvm::createJumpInstrTablesPass();
llvm::createCodeGenPreparePass();
llvm-svn: 212084
Fixes the build when no targets are selected, or no native target is built.
This also better matches up with the description/title of the example and
demonstrates how clang can be used to run C++ on constrained environments
without file IO or executable memory permissions (e.g. iOS apps).
A comment is added explaining how to extend the demo with JIT support as
needed.
llvm-svn: 212083
It used to be a feature of UBSan (it could sanitize a standalone
shared object instead of the whole program), but now it causes
more problems, like PR20165.
llvm-svn: 212064
Add module dependencies (header files, module map files) to the list of
files to check when deciding whether to rebuild a preamble. That fixes
using preambles with module imports so long as they are in
non-overridden files.
My intent is to use to unify the existing dependency collectors to the
new “DependencyCollectory” interface from this commit, starting with the
DependencyFileGenerator.
llvm-svn: 212060
This patch adds intrinsic __rdpmc to header file 'ia32intrin.h'.
Intrinsic __rdmpc can be used to read performance monitoring counters. It is
implemented as a direct call to __builtin_ia32_rdpmc.
It takes as input a value representing the index of the performance counter to
read. The value of the performance counter is then returned as a unsigned
64-bit quantity.
llvm-svn: 212053
Upon encountering a binary operator inside parentheses, assume that the
parentheses contain an expression.
Before:
MACRO('0' <= c&& c <= '9');
After:
MACRO('0' <= c && c <= '9');
llvm-svn: 212040
This worked initially but was broken by r210887.
Before:
function outer1(a, b) {
function inner1(a, b) { return a; } inner1(a, b);
} function outer2(a, b) { function inner2(a, b) { return a; } inner2(a, b); }
After:
function outer1(a, b) {
function inner1(a, b) { return a; }
inner1(a, b);
}
function outer2(a, b) {
function inner2(a, b) { return a; }
inner2(a, b);
}
Thanks to Adam Strzelecki for working on this.
llvm-svn: 212038
These don't actually require any registered backend to run.
This commit tests the water with a handful of fixes for what is a more
widespread problem.
llvm-svn: 212008
Add sign checks to deal with the fact that IR parser line/column pairs are
signed integers and sometimes invalid.
The crash path is potentially triggered by corrupt '.bc' files in practice,
though I don't have a binary input test case that can be checked-in right now.
(Unfortunately the backend itself crashes on various ill-formed '.bc' inputs so
this bandage isn't as helpful as it appears yet.)
llvm-svn: 212007
We'll want to share the implementation if anything else decides to check
for reserved names in future, so make this little snippet of code more
discoverable.
Also remove the __va_list_tag and __builtin_va_list special-case
checks. They're leftovers from before when the reserved name logic was
added.
No change in functionality.
llvm-svn: 212006
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
It reverts commits as follows:
r211866: "Driver: use GNU::Link for the Generic_GCC toolchain"
r211895: "Replace GetProgramPath("ld") with GetLinkerPath()."
r211995: "Driver: add a cygwin linker tool"
llvm-svn: 211998
This adds a linker tool for the Windows cygwin environment. This linker
invocation is significantly different from the generic ld invocation. It
requires additional parameters as well as does not accept some normal
parameters. This should fix self-hosting on Cygwin.
llvm-svn: 211995
Some time ago, I noticed that try would get resolved incorrectly for Windows
Itanium targets. Add an explicit test to exsure that exceptions are handled
correctly for Windows Itanium environments.
llvm-svn: 211992
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
This isn't 100% compatible with MSVC, but it's close enough. MSVC's /EH
flag doesn't really control exceptions so much as how to clean up after
an exception is thrown. The upshot is that cl.exe /EHs- will compile
try, throw, and catch statements with a warning, but clang-cl will
reject such constructs with a hard error. We can't compile such EH
constructs anyway, but this may matter to consumers of the AST.
Reviewers: hans
Differential Revision: http://reviews.llvm.org/D4317
llvm-svn: 211909
error handler is only registered once.
To avoid the use of std::call_once (the obvious way to do this) I've
wrapped everything up into a managed static and done the work in
a constructor. Silly, but it should be effective.
Some out-of-tree libclang users reported this to me, and I've asked them
to put together a test case which exhibits this behavior, but I wanted
to fix things ASAP since the nature of the fix is straight forward.
llvm-svn: 211905
selection re-enabled in r211900 in LLVM.
The approach (unlike r211121) doesn't rely on std::mutex or
std::call_once to avoid breaknig cygwin bots.
llvm-svn: 211901
This is a fix to the code in clang which inserts padding arguments to
ensure that the ARM backend can emit AAPCS-VFP compliant code. This code
needs to track the number of registers which have been allocated in order
to do this. When passing a very large struct (>64 bytes) by value, clang
emits IR which takes a pointer to the struct, but the backend converts this
back to passing the struct in registers and on the stack. The bug was that
this was being considered by clang to only use one register, meaning that
there were situations in which padding arguments were incorrectly emitted
by clang.
llvm-svn: 211898
The NEON intrinsics in arm_neon.h are designed to work on vectors
"as-if" loaded by (V)LDR. We load vectors "as-if" (V)LD1, so the
intrinsics are currently incorrect.
This patch adds big-endian versions of the intrinsics that does the
"obvious but dumb" thing of reversing all vector inputs and all
vector outputs. This will produce extra REVs, but we trust the
optimizer to remove them.
llvm-svn: 211893
Summary: This unbreaks our internal build after these tests were turned on in r211738.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: benlangmuir, cfe-commits
Differential Revision: http://reviews.llvm.org/D4311
llvm-svn: 211887
When we create a crashdump involving modules, we build a VFS to
reproduce the problem with. This updates the reproduction script to
use that VFS.
llvm-svn: 211876
This function is copying the entire file contents into memory repeatedly and
allocating new file IDs *each time* a source location is processed.
llvm-svn: 211874
This changes the behaviour of the driver for linking to match that of the
Generic_GCC::Assemble. The default link should use "ld" rather than "gcc" for
the linker as gcc does. This avoids the unnecessary round-tripping through gcc.
It also is much more reasonable behaviour from the user's perspective. This
should have been updated with SVN r195554 which changed the behaviour of
Generic_GCC::Assemble.
The gcc_forward test needs to be updated to mark the fact that -march is a flag
for GCC not ld. This was updated as a typo fix, but added a check for a flag
that is not a link flag.
The bindings test covers the change for testing, and thus no new test was added.
llvm-svn: 211866
At least this answers the question of whether .bc/.ll input processed by the
frontend produces identical output to the original compilation.
llvm-svn: 211853
Test that we can consume LLVM bitcode and additionally check that it produces
the same output as a direct compilation.
The feature is crashy and has gone untested until now, but we might as well
provide some coverage as long as it remains in tree.
Also test LL source input in the same way because the existing tests for that
don't look convincing.
llvm-svn: 211844
This silences false positives (leaks, use of uninitialized value) in simple
code that uses containers such as std::vector and std::list. The analyzer
cannot reason about the internal invariances of those data structures which
leads to false positives. Until we come up with a better solution to that
problem, let's just not inline the methods of the containers and allow objects
to escape whenever such methods are called.
This just extends an already existing flag "c++-container-inlining" and applies
the heuristic not only to constructors and destructors of the containers, but
to all of their methods.
We have a bunch of distinct user reports all related to this issue
(radar://16058651, radar://16580751, radar://16384286, radar://16795491
[PR19637]).
llvm-svn: 211832
Avoid a second key lookup when the back reference key is going to be
inserted in the StringMap. The string lookups in the msmangler are the
main responsible for the huge overhead when compared to the itanium
mangler. This patch makes a small but noticeable improvement.
Reviewed by: rnk
Differential Revision: http://reviews.llvm.org/D4130
Patch by Agustín Bergé!
llvm-svn: 211813
when casting a retainable object to a objc_bridge_related
CF type with the suggestion of applying the method
specified in the bridging attribute to the object.
// rdar://15932435
llvm-svn: 211807
The Command will refer back to the Tool as its source,
so it has to outlive the Command.
Having the Tool on the stack would cause us to crash
when using "clang-cl -GR -fallback", because if the
Command fails, Driver::ExecuteCompilation tries to
peek at the Command's source.
Differential Revision: http://reviews.llvm.org/D4314
llvm-svn: 211802
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
This commit implements the -fuse-ld= option, so that the user
can specify -fuse-ld=bfd to use ld.bfd.
This commit re-applies r194328 with some test case changes.
It seems that r194328 was breaking macosx or mingw build
because clang can't find ld.bfd or ld.gold in the given sysroot.
We should use -B to specify the executable search path instead.
Patch originally by David Chisnall.
llvm-svn: 211785
Previously dllimport variables inside of template arguments relied on
not using the C++11 codepath when -fms-compatibility was set.
While this allowed us to achieve compatibility with MSVC, it did so at
the expense of MingW.
Instead, try to use the DeclRefExpr we dig out of the template argument.
If it has the dllimport attribute, accept it and skip the C++11
null-pointer check.
llvm-svn: 211766
Improve the warning when building with -fprofile-instr-use and a file
appears not to have been profiled at all. This keys on whether a
function is defined in the main file or not to avoid false negatives
when one includes a header with functions that have been profiled.
llvm-svn: 211760
Summary:
The BSDs and Darwin all forward the whole 'u' group, but gcc only
forwards -u so far as I can tell. I only forward -u, since that's a
minimal change, and many people object to magically recognizing and
forwarding linker arguments.
Reviewers: chandlerc, joerg
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4304
llvm-svn: 211756
This is a follow-up to David's r211677. For the following code,
we would end up referring to 'foo' in the initializer for 'arr',
and then fail to link, because 'foo' is dllimport and needs to be
accessed through the __imp_?foo.
__declspec(dllimport) extern const char foo[];
const char* f() {
static const char* const arr[] = { foo };
return arr[0];
}
Differential Revision: http://reviews.llvm.org/D4299
llvm-svn: 211736
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
Consider the following code:
template <typename T> class Base {};
class __declspec(dllexport) class Derived : public Base<int> {}
When the base of an exported or imported class is a class template
specialization, MSVC will propagate the dll attribute to the base.
In the example code, Base<int> becomes a dllexported class.
This commit makes Clang do the proopagation when the base hasn't been
instantiated yet, and warns about it being unsupported otherwise.
This is different from MSVC, which allows changing a specialization
back and forth between dllimport and dllexport and seems to let the
last one win. Changing the dll attribute after instantiation would be
hard for us, and doesn't seem to come up in practice, so I think this
is a reasonable limitation to have.
MinGW doesn't do this kind of propagation.
Differential Revision: http://reviews.llvm.org/D4264
llvm-svn: 211725
With && at the top level of an expression, the last thing done when
emitting the expression was an unconditional jump to the cleanup block.
To reduce the amount of stepping, the DebugLoc is omitted from the
unconditional jump. This is done by clearing the IRBuilder's
"CurrentDebugLocation"*. If this is not set to some non-empty value
before the cleanup block is emitted, the cleanups don't get a location
either. If a call without a location is emitted in a function with debug
info, and that call is then inlined - bad things happen. (without a
location for the call site, the inliner would just leave the inlined
DebugLocs as they were - pointing to roots in the original function, not
inlined into the current function)
Follow up commit to LLVM will ensure that breaking the invariants of the
DebugLoc chains by having chains that don't lead to the current function
will fail assertions, so we shouldn't accidentally slip any of these
cases in anymore. Those assertions may reveal further cases that need to
be fixed in clang, though I've tried to test heavily to avoid that.
* See r128471, r128513 for the code that clears the
CurrentDebugLocation. Simply removing this code or moving the code
into IRBuilder to apply to all unconditional branches would regress
desired behavior, unfortunately.
llvm-svn: 211722
Types defined in function prototype are diagnosed earlier in C++ compilation.
They are put into declaration context where the prototype is introduced. Later on,
when FunctionDecl object is created, these types are moved into the function context.
This patch fixes PR19018 and PR18963.
Differential Revision: http://reviews.llvm.org/D4145
llvm-svn: 211718
Conditionally include x86intrin.h if we are building for x86 or x86_64.
Conditionalise definition of inline assembly routines which use x86 or x86_64
inline assembly. This is needed as clang can target Windows on ARM where these
definitions may be included into user code.
llvm-svn: 211716
[Clang part]
These patches rename the loop unrolling and loop vectorizer metadata
such that they have a common 'llvm.loop.' prefix. Metadata name
changes:
llvm.vectorizer.* => llvm.loop.vectorizer.*
llvm.loopunroll.* => llvm.loop.unroll.*
This was a suggestion from an earlier review
(http://reviews.llvm.org/D4090) which added the loop unrolling
metadata.
Patch by Mark Heffernan.
llvm-svn: 211712
The < 8 instead of <= 8 meant that a bunch of vreinterprets were not available on v8 AArch32. Simplify the guard to just !defined(aarch64) while we're at it, and enable some v8 AArch32 testing.
llvm-svn: 211686
The C++ language requires that the address of a function be the same
across all translation units. To make __declspec(dllimport) useful,
this means that a dllimported function must also obey this rule. MSVC
implements this by dynamically querying the import address table located
in the linked executable. This means that the address of such a
function in C++ is not constant (which violates other rules).
However, the C language has no notion of ODR nor does it permit dynamic
initialization whatsoever. This requires implementations to _not_
dynamically query the import address table and instead utilize a wrapper
function that will be synthesized by the linker which will eventually
query the import address table. The effect this has is, to say the
least, perplexing.
Consider the following C program:
__declspec(dllimport) void f(void);
typedef void (*fp)(void);
static const fp var = &f;
const fp fun() { return &f; }
int main() { return fun() == var; }
MSVC will statically initialize "var" with the address of the wrapper
function and "fun" returns the address of the actual imported function.
This means that "main" will return false!
Note that LLVM's optimizers are strong enough to figure out that "main"
should return true. However, this result is dependent on having
optimizations enabled!
N.B. This change also permits the usage of dllimport declarators inside
of template arguments; they are sufficiently constant for such a
purpose. Add tests to make sure we don't regress here.
llvm-svn: 211677
VarDecl provides a method getSourceRange(), which provides a more
robust way of getting the SourceRange since the TypeSourceInfo can
be null in certain cases.
Reviewed by: majnemer
Differential Revision: http://reviews.llvm.org/D4281
llvm-svn: 211667
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
Rather than having kw___if_exists be a special case of
ParseCompoundStatementBody, we can look for kw___if_exists in the big
switch over for valid statement tokens in ParseStatementOrDeclaration.
Nested __if_exists blocks are used in the DECLARE_REGISTRY_RESOURCEID
macro from atlcom.h.
llvm-svn: 211654
MSVC does not create a new scope for the body of an __if_exists compound
statement. Clang already gets this right today, but it was untested.
llvm-svn: 211650
When a user types:
int [4] foo;
assume that the user means:
int foo[4];
Update the information for 'foo' to prevent additional errors, and provide
a fix-it hint to move the brackets to the correct location.
Additionally, suggest parens for types that require it, such as:
int [4] *foo;
to:
int (*foo)[4];
llvm-svn: 211641
1) missing iterator bits needed by libstdc++4.7
Using find_if was convenient, but since operator++ wasn't a good
interface anyway, I just replaced with a range-based for loop and
removed operator++ from the directory_iterator class.
2) stop relying on order of iterating real files
llvm-svn: 211633
According to the x86-64 ABI, structures with both floating point and
integer members are split between floating-point and general purpose
registers, and consecutive 32-bit floats can be packed into a single
floating point register.
In the case of variadic functions these are stored to memory and the position
recorded in the va_list. This was already correctly implemented in
llvm.va_start.
The problem is that the code in clang for implementing va_arg was reading
floating point registers from the wrong location.
Patch by Thomas Jablin.
Fixes PR20018.
llvm-svn: 211626
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
With LocTrackingOnly there's no longer a user-facing distinction so the NDEBUG
checks can go away. (Except maybe column info, but -verify only checks line
numbers anyway.)
Also add a RUN line to validate the traditional !LocTrackingOnly case.
llvm-svn: 211622
than one method with mismatched type of same selector name.
clang issues a warning to point this out since it may cause
undefined behavior. There are cases though that some APIs
don't care about user methods and such warnings are perceived as
noise. This patch allows users to add paren delimiters around
selector name to turn off such warnings. So, @selector((save:)) will
turn off the warning. It also provides 'fixit' so user knows
what to do. // rdar://16458579
llvm-svn: 211611
Summary:
This new debug emission kind supports emitting line location
information in all instructions, but stops code generation
from emitting debug info to the final output.
This mode is useful when the backend wants to track source
locations during code generation, but it does not want to
produce debug info. This is currently used by optimization
remarks (-Rpass, -Rpass-missed and -Rpass-analysis).
When one of the -Rpass flags is used, the front end will enable
location tracking, only if no other debug option is enabled.
To prevent debug information from being generated, a new debug
info kind LocTrackingOnly causes DIBuilder::createCompileUnit() to
not emit the llvm.dbg.cu annotation. This blocks final code generation
from generating debug info in the back end.
Depends on D4234.
Reviewers: echristo, dblaikie
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4235
llvm-svn: 211610
Summary:
The dynamic linker is named ld-linux-mipsn8.so.1 when -mnan=2008 is given (or
is the default). It remains ld.so.1 for other cases.
This is necessary for MIPS32r6/MIPS64r6 since these ISA's default to -mnan=2008.
Differential Revision: http://reviews.llvm.org/D4273
llvm-svn: 211598
The address of dllimport functions can be accessed one of two ways:
- Through the IAT which is symbolically referred to with a symbol
starting with __imp_.
- Via the wrapper-function which ends up calling through the __imp_
symbol.
The problem with using the wrapper-function is that it's address will
not compare as equal in all translation units. Specifically, it will
compare unequally with the translation unit which defines the function.
This fixes PR19955.
llvm-svn: 211570
The address of dllimport variables isn't something that can be
meaningfully used in a constexpr context and isn't suitable for
evaluation at load-time. They require loads from memory to properly
evaluate.
This fixes PR19955.
Differential Revision: http://reviews.llvm.org/D4250
llvm-svn: 211568
Ensure that we properly handle the case where just the major version component
is provided by the user.
Thanks to Alp Toker for pointing out that this was not handled correctly!
llvm-svn: 211506
We were using old stat values for any files that had previously been
looked up, leading to badness. There might be a more elegant solution in
invalidating the cache for those file (since we already know which ones
they are), but it seems too likely there are existing references to
them hiding somewhere.
llvm-svn: 211504
clang_getCursorSpelling() doesn't assert on non-declarations any more and the
behaviour is covered by c-index tests.
Passes nosetests.
llvm-svn: 211482
This reverts commit r211467 which reverted r211408,r211410, it caused
crashes in test/SemaCXX/undefined-internal.cpp for i686-win32 targets.
llvm-svn: 211473
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
Make binaries built by MSVC, mingw and clang functionally equivalent. The
checks are trivially performed at runtime to eliminate functional differences
between supported configurations that used to be hard-coded.
llvm-svn: 211461
Don't try to find the MSVC version that the binaries were built with. Doing so
defeats testing by causing invalid test passes on the build servers.
Whichever Visual Studio (or clang-cl.exe) edition was used to build the clang
package, it's strictly orthogonal and has no relation to software versions
available on the user's PC.
llvm-svn: 211459
The purpose of bolding these is to make them visually distinct from
continuations (supplemental note diagnostics). Therefore, the bolding applies
to all severities _including_ remarks -- it's not in any way an indicator of
priority. Also simplify and comment.
No tests.
llvm-svn: 211447
This Lexer test unconditionally used the i128 integer literal suffix.
This suffix is only available to targets that have 128-bit arithmetic
support.
llvm-svn: 211446
Something went wrong with r211426, it is an older version of this code
and should not have been committed. It was reverted with r211434.
Original commit message:
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
This fixes PR20008.
Differential Revision: http://reviews.llvm.org/D4132
llvm-svn: 211441
This reverts commit r211426.
This broke the arm bots. The crash can be reproduced on X86 by running.
./bin/clang -cc1 -fsyntax-only -verify -fms-extensions ~/llvm/clang/test/Lexer/ms-extensions.c -triple arm-linux
llvm-svn: 211434
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
This fixes PR20008.
Differential Revision: http://reviews.llvm.org/D4132
llvm-svn: 211426
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
It's more flexible and arguably better layering to set flags to modify
compiling for diagnostics in the CC1 job themselves, rather than
tweaking the driver flags and letting them propagate.
There is one visible change this causes: crash report files will now
get preprocessed names (.i and friends).
llvm-svn: 211411
These tests relied on information that was only available for clang
builds that included asserts. Fix these tests to lift that restriction.
llvm-svn: 211408
This refactors the emission of dynamic_cast and typeid expressions so
that ABI specific knowledge lives in appropriate places. There are
quite a few benefits for having the two implementations share a common
core like sharing logic for optimization opportunities.
While we are at it, clean up the tests.
llvm-svn: 211402
When small arguments (structures < 8 bytes or "float") are passed in a
stack slot in the ppc64 SVR4 ABI, they must reside in the least
significant part of that slot. On BE, this means that an offset needs
to be added to the stack address of the parameter, but on LE, the least
significant part of the slot has the same address as the slot itself.
For the most part, this is handled in the LLVM back-end, where I just
fixed the LE case in commit r211368.
However, there is one piece of the clang front-end that is also aware of
these stack-slot offsets: PPC64_SVR4_ABIInfo::EmitVAArg. This patch
updates that routine to take endianness into account.
llvm-svn: 211370
FIXME: This fails on win32 due to ERROR_FILENAME_EXCED_RANGE if the working directory is too deep.
We should make Win32/Path.inc capable of long pathnames with '\\?\'.
llvm-svn: 211363
and is unrelated to the NEON intrinsics in arm_neon.h. On little
endian machines it works fine, however on big endian machines it
exhibits surprising behaviour:
uint32x2_t x = {42, 64};
return vget_lane_u32(x, 0); // Will return 64.
Because of this, explicitly call out that it is unsupported on big
endian machines.
This patch will emit the following warning in big-endian mode:
test.c:3:15: warning: vector initializers are a GNU extension and are not compatible with NEON intrinsics [-Wgnu]
int32x4_t x = {0, 1, 2, 3};
^
test.c:3:15: note: consider using vld1q_s32() to initialize a vector from memory, or vcombine_s32(vcreate_s32(), vcreate_s32()) to initialize from integer constants
1 warning generated.
llvm-svn: 211362
Alexey Bataev