We now have an LLVM-level nonnull attribute that can be applied to function
parameters, and we emit it for reference types (as of r209723), but did not
emit it when an __attribute__((nonnull)) was provided. Now we will.
llvm-svn: 212835
Summary:
Added some tests to see if the new warning would be silenced with a flag.
Patch by Arthur Marble <arthur@info9.net> in the context of Debian Google Summer of code 2014.
Reviewers: sylvestre.ledru
Reviewed By: sylvestre.ledru
Differential Revision: http://reviews.llvm.org/D4475
llvm-svn: 212833
- Plugins don't need to export _ZN4llvm8Registry*.
- Win32.DLL cannot merge common symbols among DLLs. Static members in llvm::Registry should be instantiated in a parent.
llvm-svn: 212821
-mx32 flag setup target environment to GNUX32 and can be used for
other 32/64-bit triplets (i386-unknown-linux, x86_64-unknown-linux) to
turn on x32 mode. Compatible with GCC -mx32 flag.
Differential Revision: http://reviews.llvm.org/D4470
llvm-svn: 212817
Returns a warning when using an unknown optimization flag.
This patch includes -finline-limit as one of those ignored flags.
More options will be moved in this group
Patch by Arthur Marble <arthur@info9.net> in the context of
Debian Google Summer of code 2014.
Reviewers: rnk, Sylvestre
llvm-svn: 212805
into their container; we won't find them there. These things are already being
merged when they're added to their primary template's folding set, so this
merging is redundant (and causes us to reject-valid because we think we've
found an odr violation).
llvm-svn: 212788
The relevant portion of C++ standard says [namespace.memdef]p3:
If the name in a friend declaration is neither qualified nor a
template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity
has been previously declared shall not consider any scopes outside the
innermost enclosing namespace.
MSVC does not implement that rule for types. If there is a type in an
enclosing namespace, they consider an unqualified tag declaration with
the same name to be a redeclaration of the type from another namespace.
Implementing compatibility is a simple matter of disabling our
implementation of this rule for types, which was added in r177473.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D4443
llvm-svn: 212784
This patch flips the default value for -gcolumn-info to be on by
default. I discussed the rationale and provided compile/size data
in:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/074290.html
This also updates the documentation and some tests that relied on
the lack of column information. Some tests had column information
in the expected output, but it was wrong (the tsan tests). Others
were using the driver to execute.
llvm-svn: 212781
Teach UBSan vptr checker to ignore technically invalud down-casts on
blacklisted types.
Based on http://reviews.llvm.org/D4407 by Byoungyoung Lee!
llvm-svn: 212770
Originally committed in r211722, this fixed one case of dtor calls being
emitted without locations (this causes problems for debug info if the
call is then inlined), this caught only some of the cases.
Instead of trying to re-enable the location before the cleanup, simply
re-enable the location immediately after the unconditional branches in
question using a scoped device to ensure the no-location state doesn't
leak out arbitrarily.
llvm-svn: 212761
This patch adds support for respecting the ABI and type alignment
of aggregates passed by value. Currently, all aggregates are aligned
at 8 bytes in the parameter save area. This is incorrect for two
reasons:
- Aggregates that need alignment of 16 bytes or more should be aligned
at 16 bytes in the parameter save area. This is implemented by
using an appropriate "byval align" attribute in the IR.
- Aggregates that need alignment beyond 16 bytes need to be dynamically
realigned by the caller. This is implemented by setting the Realign
flag of the ABIArgInfo::getIndirect call.
In addition, when expanding a va_arg call accessing a type that is
aligned at 16 bytes in the argument save area (either one of the
aggregate types as above, or a vector type which is already aligned
at 16 bytes), code needs to align the va_list pointer accordingly.
Reviewed by Hal Finkel.
llvm-svn: 212743
Allow diagnostic checks that originate in included files to be matched without necessarily determining the line number that the diagnostic occurs on. The new syntax replaces the line number with '*'. This extension is limited to diagnostics in included files and may be used where the include file is not part of the test-suite itself.
Expected uses are for diagnostics originating in system headers, or for users who use -verify in testing 3rd-party library code where the location of diagnostics in header files may change from revision to revision and their precise location is not important to the success of the test-case.
llvm-svn: 212735
This patch adds support for passing arguments of non-Altivec vector type
(i.e. defined via attribute ((vector_size (...)))) on powerpc64-linux.
While such types are not mentioned in the formal ABI document, this
patch implements a calling convention compatible with GCC:
- Vectors of size < 16 bytes are passed in a GPR
- Vectors of size > 16 bytes are passed via reference
Note that vector types with a number of elements that is not a power
of 2 are not supported by GCC, so there is no pre-existing ABI to
follow. We choose to pass those (of size < 16) as if widened to the
next power of two, so they might end up in a vector register or
in a GPR. (Sizes > 16 are always passed via reference as well.)
Reviewed by Hal Finkel.
llvm-svn: 212734
Comdat IR references were mistakenly printed for aliases when they
passed through the IR/AsmWriter code.
This makes clang's tests not check for the existance of these wrongly
printed comdat references.
llvm-svn: 212733
This new checker, alpha.core.TestAfterDivZero, catches issues like this:
int sum = ...
int avg = sum / count; // potential division by zero...
if (count == 0) { ... } // ...caught here
Because the analyzer does not necessarily explore /all/ paths through a program,
this check is restricted to only work on zero checks that immediately follow a
division operation (/ % /= %=). This could later be expanded to handle checks
dominated by a division operation but not necessarily in the same CFG block.
Patch by Anders Rönnholm! (with very minor modifications by me)
llvm-svn: 212731
Summary:
* Support the multilib layout used by the mips-img-linux-gnu
* Recognize mips{,64}{,el}-img-linux-gnu as being aliases of mips-img-linux-gnu
* Use the correct dynamic linker for mips-img-linux-gnu
* Make mips32r6/mips64r6 the default CPU for mips-img-linux-gnu
Subscribers: mpf
Differential Revision: http://reviews.llvm.org/D4436
llvm-svn: 212719
Although this is nominally a -W option, we actually handle it in the driver
exactly as an f-group flag that's translated directly to -mllvm.
That means f_Group (and unintuitively, not W_Group) has the semantics we want
to make it behave like a standard warning flag: no automatic forwarding, no
warning for link invocations and compile-only.
Silences diagnostics like:
[691/1545] Linking CXX executable bin/llvm-diff
clang-3.5: warning: argument unused during compilation: '-Wframe-larger-than=2048'
(Hopefully we can move towards handling these in the frontend but that'll
require some infrastructure work.)
llvm-svn: 212670
The sret paramater consumes the register after the implicit 'this'
parameter, as with other calling conventions.
Fixes PR20278, which turned out to be very easy.
llvm-svn: 212669
Turn llvm::SpecialCaseList into a simple class that parses text files in
a specified format and knows nothing about LLVM IR. Move this class into
LLVMSupport library. Implement two users of this class:
* DFSanABIList in DFSan instrumentation pass.
* SanitizerBlacklist in Clang CodeGen library.
The latter will be modified to use actual source-level information from frontend
(source file names) instead of unstable LLVM IR things (LLVM Module identifier).
Remove dependency edge from ClangCodeGen/ClangDriver to LLVMTransformUtils.
No functionality change.
llvm-svn: 212643
gcc supports this behavior and it is pervasively used inside the Linux
kernel.
Note that both gcc and clang will reject code that attempts to do this
in a C++ language mode.
This fixes PR17998.
llvm-svn: 212631
The clang -cc1as options are nearly a strict subset of -cc1. Instead of
duplicating the definitions and documentation, let's go ahead and share the
definitions in a similar way the current handling of combined driver and
frontend flags, eliminating some of the vestigial legacy surrounding the
assembler subcommand.
llvm-svn: 212620
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
Though not completely identical, make former
IndentFunctionDeclarationAfterType change this flag for backwards
compatibility (it is somewhat close in meaning and better the err'ing on
an unknown config flag).
llvm-svn: 212597
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
Hal Finkel