Some Windows SDK classes, for example
Windows::Storage::Streams::IBufferByteAccess, use the ATL way of spelling
attributes:
[uuid("....")] class IBufferByteAccess {};
To be able to use __uuidof() to grab the uuid off these types, clang needs to
support uuid as a Microsoft attribute. There was already code to skip Microsoft
attributes, extend that to look for uuid and parse it. Use the new "Microsoft"
attribute type added in r280575 (and r280574, r280576) for this.
Final part of https://reviews.llvm.org/D23895
llvm-svn: 280578
Clang tests for verifying the following syntaxes:
1. 0xNN and NNh are accepted as valid hexadecimal numbers, but 0xNNh is not.
0xNN and NNh may come with optional U or L suffix.
2. NNb is accepted as a valid binary (base-2) number, but 0bNN is not.
NNb may come with optional U or L suffix.
Differential Revision: https://reviews.llvm.org/D22112
llvm-svn: 280556
This patch allows us to perform incompatible pointer conversions when
resolving overloads in C. So, the following code will no longer fail to
compile (though it will still emit warnings, assuming the user hasn't
opted out of them):
```
void foo(char *) __attribute__((overloadable));
void foo(int) __attribute__((overloadable));
void callFoo() {
unsigned char bar[128];
foo(bar); // selects the char* overload.
}
```
These conversions are ranked below all others, so:
A. Any other viable conversion will win out
B. If we had another incompatible pointer conversion in the example
above (e.g. `void foo(int *)`), we would complain about
an ambiguity.
Differential Revision: https://reviews.llvm.org/D24113
llvm-svn: 280553
Summary:
This attribute specifies expectations about the initialization of static and
thread local variables. Specifically that the variable has a
[constant initializer](http://en.cppreference.com/w/cpp/language/constant_initialization)
according to the rules of [basic.start.static]. Failure to meet this expectation
will result in an error.
Static objects with constant initializers avoid hard-to-find bugs caused by
the indeterminate order of dynamic initialization. They can also be safely
used by other static constructors across translation units.
This attribute acts as a compile time assertion that the requirements
for constant initialization have been met. Since these requirements change
between dialects and have subtle pitfalls it's important to fail fast instead
of silently falling back on dynamic initialization.
```c++
// -std=c++14
#define SAFE_STATIC __attribute__((require_constant_initialization)) static
struct T {
constexpr T(int) {}
~T();
};
SAFE_STATIC T x = {42}; // OK.
SAFE_STATIC T y = 42; // error: variable does not have a constant initializer
// copy initialization is not a constant expression on a non-literal type.
```
This attribute can only be applied to objects with static or thread-local storage
duration.
Reviewers: majnemer, rsmith, aaron.ballman
Subscribers: jroelofs, cfe-commits
Differential Revision: https://reviews.llvm.org/D23385
llvm-svn: 280525
Summary:
This attribute specifies expectations about the initialization of static and
thread local variables. Specifically that the variable has a
[constant initializer](http://en.cppreference.com/w/cpp/language/constant_initialization)
according to the rules of [basic.start.static]. Failure to meet this expectation
will result in an error.
Static objects with constant initializers avoid hard-to-find bugs caused by
the indeterminate order of dynamic initialization. They can also be safely
used by other static constructors across translation units.
This attribute acts as a compile time assertion that the requirements
for constant initialization have been met. Since these requirements change
between dialects and have subtle pitfalls it's important to fail fast instead
of silently falling back on dynamic initialization.
```c++
// -std=c++14
#define SAFE_STATIC __attribute__((require_constant_initialization)) static
struct T {
constexpr T(int) {}
~T();
};
SAFE_STATIC T x = {42}; // OK.
SAFE_STATIC T y = 42; // error: variable does not have a constant initializer
// copy initialization is not a constant expression on a non-literal type.
```
This attribute can only be applied to objects with static or thread-local storage
duration.
Reviewers: majnemer, rsmith, aaron.ballman
Subscribers: jroelofs, cfe-commits
Differential Revision: https://reviews.llvm.org/D23385
llvm-svn: 280516
Summary:
We want wasm and asmjs to have matching ABIs, and right now asmjs uses
unsigned int for its size_t. This causes exported symbols in libcxx to
not match and can cause weird breakage where libcxx doesn't get linked
as a result. Long-term we probably want wasm32, wasm64, and asmjs to
all use unsigned long, but that would cause unnecessary ABI churn for
asmjs so defer that until we can make all the ABI changes at once.
Patch by Jacob Gravelle
Differential Revision: https://reviews.llvm.org/D24134
llvm-svn: 280420
textually included, create an ImportDecl just as we would if we reached a
#include of any other modular header. This is necessary in order to correctly
determine the set of variables to initialize for an imported module.
This should hopefully make the modules selfhost buildbot green again.
llvm-svn: 280409
This patch also introduces AnalysisOrderChecker which is intended for testing
of callback call correctness.
Differential Revision: https://reviews.llvm.org/D23804
llvm-svn: 280367
Some FileIDs that may be used by PlistDiagnostics were not added while building
a list of pieces. This caused assertion violation in GetFID() function.
This patch adds some missing FileIDs to avoid the assertion. It also contains
small refactoring of PlistDiagnostics::FlushDiagnosticsImpl().
Patch by Aleksei Sidorin, Ilya Palachev.
Differential Revision: https://reviews.llvm.org/D22090
llvm-svn: 280360
Since some profiling tools, such as gprof, ftrace, and uftrace, use
-pg option to generate a mcount function call at the entry of each
function. Function invocation can be detected by this hook function.
But mcount insertion is done before function inlining phase in clang,
sometime a function that already has a mcount call can be inlined in the
middle of another function.
This patch adds an attribute "counting-function" to each function
rather than emitting the mcount call directly in frontend so that this
attribute can be processed in backend. Then the mcount calls can be
properly inserted in backend after all the other optimizations are
completed.
Link: https://llvm.org/bugs/show_bug.cgi?id=28660
Reviewers: hans, rjmccall, hfinkel, rengolin, compnerd
Subscribers: shenhan, cfe-commits
Differential Revision: https://reviews.llvm.org/D22666
llvm-svn: 280355
declaration has a dependent type.
This fixes a bug where clang errors out on a valid code.
rdar://problem/28051467
Differential Revision: https://reviews.llvm.org/D24110
llvm-svn: 280330
explicit specialization to a warning for C++98 mode (this is a defect report
resolution, so per our informal policy it should apply in C++98), and turn
the warning on by default for C++11 and later. In all cases where it fires, the
right thing to do is to remove the pointless explicit instantiation.
llvm-svn: 280308
-fprofile-dir=path allows the user to specify where .gcda files should be
emitted when the program is run. In particular, this is the first flag that
causes the .gcno and .o files to have different paths, LLVM is extended to
support this. -fprofile-dir= does not change the file name in the .gcno (and
thus where lcov looks for the source) but it does change the name in the .gcda
(and thus where the runtime library writes the .gcda file). It's different from
a GCOV_PREFIX because a user can observe that the GCOV_PREFIX_STRIP will strip
paths off of -fprofile-dir= but not off of a supplied GCOV_PREFIX.
To implement this we split -coverage-file into -coverage-data-file and
-coverage-notes-file to specify the two different names. The !llvm.gcov
metadata node grows from a 2-element form {string coverage-file, node dbg.cu}
to 3-elements, {string coverage-notes-file, string coverage-data-file, node
dbg.cu}. In the 3-element form, the file name is already "mangled" with
.gcno/.gcda suffixes, while the 2-element form left that to the middle end
pass.
llvm-svn: 280306
I tested the cases involving split-dwarf + gmlt +
no-split-dwarf-inlining, but didn't verify the simpler case without
gmlt.
The logic is, admittedly, a little hairy, but seems about as simple as I
could wrangle it.
llvm-svn: 280290
indirect virtual bases. We don't need to be able to invoke such an assignment
operator from the derived class, and we shouldn't delete the derived assignment
op if we can't do so.
llvm-svn: 280288
Classes with no virtual methods or whose virtual methods were all
inherited from virtual bases don't have a vfptr at offset zero. We were
crashing attempting to get the layout of that non-existent vftable.
We don't need any vshape info in this case because the debugger can
infer it from the base class information. The current class may not
introduce any virtual methods if we are in this situation.
llvm-svn: 280287
The shape is really just the number of methods in the vftable, since we
don't support 16 bit far calls. All calls are near. Encode this number
in the size of the artificial __vtbl_ptr_type DIDerivedType that we
generate. For DWARF, this will be a normal pointer, but for codeview
this will be a wide pointer that gets pattern matched into a
VFTableShape record. Insert this type into the element list of all
dynamic classes when emitting CodeView, so that the backend can emit the
shape even if the vptr lives in a primary base class.
Fixes PR28150
llvm-svn: 280255
-ffast-math to CC1, but it included a wrong llvm regression tests which was
removed in r280065. Although regression test noexceptionsfpmath.c makes sure
-fno-trapping-math ends up as a function attribute, this adds a test that
explicitly checks the driver output for -fno-trapping-math.
llvm-svn: 280227
These clang tests check diagnostics from the backend by giving it an unvectorizable loop. This loop is now vectorized :/
Make it really unvectorizable by making it unprofitable to ifconvert.
llvm-svn: 280220
In most cases these code regions are just redundant, but sometimes they
could be assigned to the counter of the parent code region instead of
the counter of the nested block.
Differential Revision: https://reviews.llvm.org/D23987
llvm-svn: 280199
These will be reused when removing some builtins from avx512vldqintrin.h and this will make the tests for that change show a better number of vector elements.
llvm-svn: 280196
within the instantiation of that same specialization. This could previously
happen for eagerly-instantiated function templates, variable templates,
exception specifications, default arguments, and a handful of other cases.
We still have an issue here for default template arguments that recursively
make use of themselves and likewise for substitution into the type of a
non-type template parameter, but in those cases we're producing a different
entity each time, so they should instead be caught by the instantiation depth
limit. However, currently we will typically run out of stack before we reach
it. :(
llvm-svn: 280190
'cc1' is a valid sequence of hexadecimal and sometimes can occur in the path
when testing. This can lead to FileCheck matching the incorrect occurance
of the 'cc1' string and causing a test failure. Join two adjacent flags
together into one check to prevent this.
llvm-svn: 280189
Fix a crash when relexing the underlying memory buffer to find incorrect
arguments to NSLocalizedString(). With precompiled headers, the raw
buffer may be NULL. Instead, use the source manager to get the buffer,
which will lazily create the buffer for precompiled headers.
rdar://problem/27429091
llvm-svn: 280174
On Windows, static libraries are named lib<name>.lib while import libraries are
named <name>.lib. Use the appropriate naming on itanium and msvc environments.
This is setup properly so that if a dynamic builtins is used on Windows, it
would do the right thing, although this is not currently wired through the
driver (i.e. there is no equivalent to -{shared,static}-gcc).
llvm-svn: 280169
This adds support for modules that require (no-)gnu-inline-asm
environment, such as the compiler builtin cpuid submodule.
This is the gnu-inline-asm variant of https://reviews.llvm.org/D23871
Differential Revision: https://reviews.llvm.org/D23905
rdar://problem/26931199
llvm-svn: 280159
This reverts commit r280142. Mehdi suggested a better way to fix up the
test: just create a fake libLTO.dylib and tell the driver where to find
it. Patch incoming...
llvm-svn: 280149
Running 'check-clang' on a stock checkout of llvm+clang doesn't work on
Darwin, because test/Driver/darwin-ld-lto.c can't find libLTO.dylib. Add
libLTO as a clang test dependency on Darwin to fix the problem.
Note: We don't have this issue with check-all because libLTO is in the
test-depends target.
Differential Revision: https://reviews.llvm.org/D24042
llvm-svn: 280142
r280133. Original commit message:
C++ Modules TS: driver support for building modules.
This works as follows: we add --precompile to the existing gamut of options for
specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag
specifies that an input is taken to the precompilation step and no further, and
this can be specified when building a .pcm from a module interface or when
building a .pch from a header file.
The .cppm extension (and some related extensions) are implicitly recognized as
C++ module interface files. If --precompile is /not/ specified, the file is
compiled (via a .pcm) to a .o file containing the code for the module (and then
potentially also assembled and linked, if -S, -c, etc. are not specified). We
do not yet suppress the emission of object code for other users of the module
interface, so for now this will only work if everything in the .cppm file has
vague linkage.
As with the existing support for module-map modules, prebuilt modules can be
provided as compiler inputs either via the -fmodule-file= command-line argument
or via files named ModuleName.pcm in one of the directories specified via
-fprebuilt-module-path=.
This also exposes the -fmodules-ts cc1 flag in the driver. This is still
experimental, and in particular, the concrete syntax is subject to change as
the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does
not enable support for implicitly loading module maps nor building modules via
the module cache, but those features can be turned on separately and used in
conjunction with the Modules TS support.
llvm-svn: 280134
to CC1, which are translated to function attributes and can e.g. be mapped on
build attributes FP_exceptions and FP_denormal. Setting these build attributes
allows better selection of floating point libraries.
Differential Revision: https://reviews.llvm.org/D23840
llvm-svn: 280064
The PPC64 DWARF register-size table did not match the ABI specification (or
GCC, for that matter). Fix that, and add a regression test.
Fixes PR27931.
llvm-svn: 280053
This works as follows: we add --precompile to the existing gamut of options for
specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag
specifies that an input is taken to the precompilation step and no further, and
this can be specified when building a .pcm from a module interface or when
building a .pch from a header file.
The .cppm extension (and some related extensions) are implicitly recognized as
C++ module interface files. If --precompile is /not/ specified, the file is
compiled (via a .pcm) to a .o file containing the code for the module (and then
potentially also assembled and linked, if -S, -c, etc. are not specified). We
do not yet suppress the emission of object code for other users of the module
interface, so for now this will only work if everything in the .cppm file has
vague linkage.
As with the existing support for module-map modules, prebuilt modules can be
provided as compiler inputs either via the -fmodule-file= command-line argument
or via files named ModuleName.pcm in one of the directories specified via
-fprebuilt-module-path=.
This also exposes the -fmodules-ts cc1 flag in the driver. This is still
experimental, and in particular, the concrete syntax is subject to change as
the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does
not enable support for implicitly loading module maps nor building modules via
the module cache, but those features can be turned on separately and used in
conjunction with the Modules TS support.
llvm-svn: 280035
If there were several nested statements arranged in a way that all of them
end up with the same macro, then the expansion of this macro was assigned
with all the corresponding counters of these statements.
As a result, the wrong counter value was shown for the macro in llvm-cov.
This patch fixes the issue by preventing adding a counter for an expanded
source range if it already has an assigned counter, which is expected
to come from the most specific statement.
Differential Revision: https://reviews.llvm.org/D23160
llvm-svn: 279962
Clang always assumes that files are utf-8. If an invalidly encoded character is
used in an identifier, clang always errors. If it's used in a character
literal, clang warns Winvalid-source-encoding (on by default). Clang never
checks the encoding of things in comments (adding this seems like a nice
feature if it doesn't impact performance).
For cl.exe /utf-8 (which enables /validate-charset), if a bad character is used
in an identifier, it emits both an error and a warning. If it's used in a
literal or a comment, it emits a warning.
So mapping /validate-charset to -Winvalid-source-encoding seems like a fairly
decent fit.
https://reviews.llvm.org/D23945
llvm-svn: 279872
This is triggered when we are compiling an implementation of a module,
it has relative includes to a VFS-mapped module with umbrella headers.
Currently we will find the real path to headers under the umbrella directory,
but the umbrella directories are using virtual path.
rdar://27951255
Thanks Ben and Richard for reviewing the patch!
Differential Revision: http://reviews.llvm.org/D23858
llvm-svn: 279838
Otherwise we can't handle secondary base classes at offsets greater than
2**24. This agrees with libstdc++abi.
We could extend this change to other LLP64 platforms, but then we would
want to update libc++abi and it would require additional review.
Fixes PR29116
llvm-svn: 279786
Clang tracks only start columns, not start-end ranges. CodeView allows for that, but the VS debugger doesn't handle anything less than a complete range well--it either highlights the wrong part of a statement or truncates source lines in the assembly view. It's better to have no column information at all.
So by default, we'll omit the column information for CodeView targeting Windows.
Since the column info is still useful for sanitizers, I've promoted -gcolumn-info (and -gno-column-info) to a CoreOption and added a couple tests to make sure that works for clang-cl.
Differential Revision: https://reviews.llvm.org/D23720
llvm-svn: 279765
This isn't exactly what MSVC does, unfortunately. MSVC does not pass
objects with destructors but no copy constructors by address. More ARM
expertise is required to really understand what should be done here.
Fixes PR29136.
llvm-svn: 279764
Emit proper diagnostics when -Wdocumentation is used with constructs such as:
template<typename T>
using fn = int(T aaa, int ccc);
Previously clang wouldn't recognize the function and complain with
'comment that is not attached to a function declaration'.
Differential Revision: https://reviews.llvm.org/D23860
rdar://problem/27300695
llvm-svn: 279754
If the inline info is not duplicated into the skeleton CU, then there's
value in using -gsplit-dwarf and -gmlt together (to keep all those extra
subprograms out of the skeleton CU, while also producing smaller .dwo
files)
llvm-svn: 279687
per-frame stack usage enough to cause it to hit our stack limit. This is not
ideal; we should find a better way of dealing with this, such as increasing
our stack allocation when built with ASan.
llvm-svn: 279668
Give appropriate warnings with -Wdocumentation for @param comments
that refer to function aliases defined with 'using'. Very similar
to typedef's behavior. This does not add support for
TypeAliasTemplateDecl yet.
Differential Revision: https://reviews.llvm.org/D23783
rdar://problem/27300695
llvm-svn: 279662
In cases where .dwo/.dwp files are guaranteed to be available, skipping
the extra online (in the .o file) inline info can save a substantial
amount of space - see the original r221306 for more details there.
llvm-svn: 279651
Summary:
This patch adds the capability to bundle object files in sections of the host binary using a designated naming convention for these sections. This patch uses the functionality of the object reader already in the LLVM library to read bundled files, and invokes clang with the incremental linking options to create bundle files.
Bundling files involves creating an IR file with the contents of the bundle assigned as initializers of globals binded to the designated sections. This way the bundling implementation is agnostic of the host object format.
The features added by this patch were requested in the RFC discussion in http://lists.llvm.org/pipermail/cfe-dev/2016-February/047547.html.
Reviewers: echristo, tra, jlebar, hfinkel, ABataev, Hahnfeld
Subscribers: mkuron, whchung, cfe-commits, andreybokhanko, Hahnfeld, arpith-jacob, carlo.bertolli, mehdi_amini, caomhin
Differential Revision: https://reviews.llvm.org/D21851
llvm-svn: 279634
Summary:
One of the goals of programming models that support offloading (e.g. OpenMP) is to enable users to offload with little effort, by annotating the code with a few pragmas. I'd also like to save users the trouble of changing their existent applications' build system. So having the compiler always return a single file instead of one for the host and each target even if the user is doing separate compilation is desirable.
This diff proposes a tool named clang-offload-bundler (happy to change the name if required) that is used to bundle files associated with the same user source file but different targets, or to unbundle a file into separate files associated with different targets.
This tool supports the driver support for OpenMP under review in http://reviews.llvm.org/D9888. The tool is used there to enable separate compilation, so that the very first action on input files that are not source files is a "unbundling action" and the very last non-linking action is a "bundling action".
The format of the bundled files is currently very simple: text formats are concatenated with comments that have a magic string and target identifying triple in between, and binary formats have a header that contains the triple and the offset and size of the code for host and each target.
The goal is to improve this tool in the future to deal with archive files so that each individual file in the archive is properly dealt with. We see that archives are very commonly used in current applications to combine separate compilation results. So I'm convinced users would enjoy this feature.
This tool can be used like this:
`clang-offload-bundler -targets=triple1,triple2 -type=ii -inputs=a.triple1.ii,a.triple2.ii -outputs=a.ii`
or
`clang-offload-bundler -targets=triple1,triple2 -type=ii -outputs=a.triple1.ii,a.triple2.ii -inputs=a.ii -unbundle`
I implemented the tool under clang/tools. Please let me know if something like this should live somewhere else.
This patch is prerequisite for http://reviews.llvm.org/D9888.
Reviewers: hfinkel, rsmith, echristo, chandlerc, tra, jlebar, ABataev, Hahnfeld
Subscribers: whchung, caomhin, andreybokhanko, arpith-jacob, carlo.bertolli, mehdi_amini, guansong, Hahnfeld, cfe-commits
Differential Revision: https://reviews.llvm.org/D13909
llvm-svn: 279632
to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly
determine whether a function definition is visible, and mark both the function
and the template as visible when merging function template definitions to
provide hasVisibleDefinition with the relevant information.
The change to always pass the right declaration as the PatternDef to
DiagnoseUninstantiableTemplate also caused those checks to happen before other
diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the
same situations, so I sunk the relevant diagnostics into
DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes
in reviews.llvm.org/D23492 by Vassil Vassilev.
This reinstates r279486, reverted in r279500, with a fix to
DiagnoseUninstantiableTemplate to only mark uninstantiable explicit
instantiation declarations as invalid if we actually diagnosed them. (When we
trigger an explicit instantiation of a class member from an explicit
instantiation declaration for the class, it's OK if there is no corresponding
definition and we certainly don't want to mark the member invalid in that
case.) This previously caused a build failure during bootstrap.
llvm-svn: 279557
/Brepro means we want reproducible builds, i.e. we _don't_ want the timestamp
that's needed to be compatible with the incremental linker.
https://reviews.llvm.org/D23805
llvm-svn: 279555
iOS (and other 32-bit ARM variants) always require a valid frame pointer to
improve backtraces. Previously the -fomit-frame-pointer and
-momit-leaf-frame-pointer options were being silently discarded via hacks in
the backend. It's better if Clang configures itself to emit the correct IR and
warns about (ignored) attempts to override this.
llvm-svn: 279546
clang already treats all inputs as utf-8. Warn if anything but utf-8 is passed.
Do this by mapping source-charset to finput-charset, which already behaves like
this. Slightly tweak finput-charset to accept "utf-8" case-insensitively. This
matches gcc's and cl.exe's behavior, and IANA says that character set names are
case-insensitive.
https://reviews.llvm.org/D23807
llvm-svn: 279531
If a call expression represents a method call of a class template,
and the method itself isn't templated, then the method may be considered
to be a template instantiation without template specialization arguments.
No longer crash when we could not find template specialization arguments.
Patch by Raphael Isemann!
Differential Revision: https://reviews.llvm.org/D23780
llvm-svn: 279529
to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly
determine whether a function definition is visible, and mark both the function
and the template as visible when merging function template definitions to
provide hasVisibleDefinition with the relevant information.
The change to always pass the right declaration as the PatternDef to
DiagnoseUninstantiableTemplate also caused those checks to happen before other
diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the
same situations, so I sunk the relevant diagnostics into
DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes
in reviews.llvm.org/D23492 by Vassil Vassilev.
llvm-svn: 279486
in isDefinedInClangModule() and assume that the incomplete definition
is not defined in the module.
This broke the -gmodules self host recently.
rdar://problem/27894367
llvm-svn: 279485
Fix crash-on-invalid in ObjC Sema by avoiding to rebuild a message
expression to a 'super' class in case the method to call does not exist
(i.e. comes from another missing identifier).
In this case, the typo transform is invoked upon the message expression
in an attempt to solve a typo in a 'super' call parameters, but it
crashes since it assumes the method to call has a valid declaration.
rdar://problem/27305403
llvm-svn: 279481
Structs are currently handled as pointer + byval, which makes AMDGPU
LLVM backend generate incorrect code when structs are used. This patch
changes struct argument to be handled directly and without flattening,
which Clover (Mesa 3D Gallium OpenCL state tracker) will be able to
handle. Flattening would expand the struct to individual elements and
pass each as a separate argument, which Clover can not
handle. Furthermore, such expansion does not fit the OpenCL
programming model which requires to explicitely specify each argument
index, size and memory location.
Patch by Vedran Miletić
llvm-svn: 279463
If they are, we end up with the last intermediary output preserved
in the current directory after compilation.
Added a test case to verify that we're using appropriate filenames
for outputs of different phases.
Differential Revision: https://reviews.llvm.org/D23526
llvm-svn: 279455
Craig Topper