The logic for lowering profiling counters has been moved to an LLVM
pass. Emit the intrinsics rather than duplicating the whole pass in
clang.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223683 91177308-0d34-0410-b5e6-96231b3b80d8
An updated implemnentation of VLA types capturing based on previously committed solution for Lambdas.
This version captures the whole VLA type instead of particular variables which are part of VLA size expression and allows to use previusly calculated size of VLA type in captured regions. Required for OpenMP.
Differential Revision: http://reviews.llvm.org/D5099
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220850 91177308-0d34-0410-b5e6-96231b3b80d8
Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1).
Reviewed by Richard Smith
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219589 91177308-0d34-0410-b5e6-96231b3b80d8
Includes parsing and semantic analysis for 'omp teams' directive support from OpenMP 4.0. Adds additional analysis to 'omp target' directive with 'omp teams' directive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219385 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r219197 because it broke ARM self-hosting buildbots with
segmentation fault errors in many tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219289 91177308-0d34-0410-b5e6-96231b3b80d8
Includes parsing and semantic analysis for 'omp teams' directive support from OpenMP 4.0. Adds additional analysis to 'omp target' directive with 'omp teams' directive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219197 91177308-0d34-0410-b5e6-96231b3b80d8
If control falls off the end of a function after an __asm block, MSVC
assumes that the inline assembly filled the EAX and possibly EDX
registers with an appropriate return value. This functionality is used
in inline functions returning 64-bit integers in system headers, so we
need some amount of compatibility.
This is implemented in Clang by adding extra output constraints to every
inline asm block, and storing the resulting output registers into the
return value slot. If we see an asm block somewhere in the function
body, we emit a normal epilogue instead of marking the end of the
function with a return type unreachable.
Normal returns in functions not using this functionality will overwrite
the return value slot, and in most cases LLVM should be able to
eliminate the dead stores.
Fixes PR17201.
Reviewed By: majnemer
Differential Revision: http://reviews.llvm.org/D5177
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217187 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to r215768 (which fixed the same case for while loops). To quote
r215768's commit message:
"A little test case simplification - this could be simplified further,
though there are certainly interesting connections to the if/else
construct so I'm hesitant to remove that entirely though it does appear
somewhat unrelated.
(similar fix to r215766, related to PR19864)"
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216297 91177308-0d34-0410-b5e6-96231b3b80d8
for loops introduce two scopes - one for the outer loop variable and its
initialization, and another for the body of the loop, including any
variable declared inside the loop condition.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216288 91177308-0d34-0410-b5e6-96231b3b80d8
A little test case simplification - this could be simplified further,
though there are certainly interesting connections to the if/else
construct so I'm hesitant to remove that entirely though it does appear
somewhat unrelated.
(similar fix to r215766, related to PR19864)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215768 91177308-0d34-0410-b5e6-96231b3b80d8
This avoids debuggers stepping to strange places (like the last
statement in the loop body, or the first statement in the if).
This is not the whole answer, though - similar bugs no doubt exist in
other loops (patches to follow) and attributing exception handling code
to the correct line is also tricky (based on the previous fix to
PR19864, exception handling is still erroneously attributed to the 'if'
line).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215766 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is necessary to support constant expressions which replaces the integer value in the loop hint attribute with an expression. The integer value was also storing the pragma’s state for options like vectorize(enable/disable) and the pragma unroll and nounroll directive. The state variable is introduced to hold the state of those options/pragmas. This moves the validation of the state (keywords) from SemaStmtAttr handler to the loop hint annotation token handler.
Resubmit with changes to try to fix the build-bot issue.
Reviewed by Aaron Ballman
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214432 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is necessary to support constant expressions which replaces the integer value in the loop hint attribute with an expression. The integer value was also storing the pragma’s state for options like vectorize(enable/disable) and the pragma unroll and nounroll directive. The state variable is introduced to hold the state of those options/pragmas. This moves the validation of the state (keywords) from SemaStmtAttr handler to the loop hint annotation token handler.
Reviewed by Aaron Ballman
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214333 91177308-0d34-0410-b5e6-96231b3b80d8
This isn't nearly as elaborate as the GCC inline asm which emits an
array of source locations, but it's very, very hard to trigger backend
diagnostics in MS inline asm because we parse it up front with good
source information, unlike GCC inline asm.
Currently I can trigger a "inline assembly requires more registers than
available" diagnostic with this code:
void foo();
void bar() {
__asm pusha
__asm call foo
__asm popa
}
However, if I committed that as a test case, I would have to remove it
once I fix PR20052.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214141 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212761 91177308-0d34-0410-b5e6-96231b3b80d8
Codegen is still missing (and I won't work on that), but __leave is now
as implemented as __try and friends.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212425 91177308-0d34-0410-b5e6-96231b3b80d8
[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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211712 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r211096. Looks like it broke the msvc build:
SemaOpenMP.cpp(140) : error C4519: default template arguments are only allowed on a class template
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211113 91177308-0d34-0410-b5e6-96231b3b80d8
Since the continuation block of the if statement is emitted within the
condition scope this had the undesirable effect of creating a line table
entry at the end of the then or else statement, a line that may have never
been executed.
PR19864 / rdar://problem/17052973
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209764 91177308-0d34-0410-b5e6-96231b3b80d8
condition to a constant and emit only the relevant statement. In that
case, we were previously creating the epilog jump destination, a cleanup
scope, and emitting any condition variable into it. Instead, we can emit
the condition variable (if we have one) into the cleanup scope used for
the entire folded case sequence. We avoid creating a jump dest, a basic
block, and an extra cleanup scope. Win!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207888 91177308-0d34-0410-b5e6-96231b3b80d8
CapturedStmt was being ignored by instrumentation based profiling, and
its counters attributed to the containing function. Instead, we need
to treat this as a top level entity, like we do with blocks.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206231 91177308-0d34-0410-b5e6-96231b3b80d8
are not associated with any source lines.
Previously, if the Location of a Decl was empty, EmitFunctionStart would
just keep using CurLoc, which would sometimes be correct (e.g., thunks)
but in other cases would just point to a hilariously random location.
This patch fixes this by completely eliminating all uses of CurLoc from
EmitFunctionStart and rather have clients explicitly pass in a
SourceLocation for the function header and the function body.
rdar://problem/14985269
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205999 91177308-0d34-0410-b5e6-96231b3b80d8
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205100 91177308-0d34-0410-b5e6-96231b3b80d8
r203364: what was use_iterator is now user_iterator, and there is
a use_iterator for directly iterating over the uses.
This also switches to use the range-based APIs where appropriate.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203365 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, we made one traversal of the AST prior to codegen to assign
counters to the ASTs and then propagated the count values during codegen. This
patch now adds a separate AST traversal prior to codegen for the
-fprofile-instr-use option to propagate the count values. The counts are then
saved in a map from which they can be retrieved during codegen.
This new approach has several advantages:
1. It gets rid of a lot of extra PGO-related code that had previously been
added to codegen.
2. It fixes a serious bug. My original implementation (which was mailed to the
list but never committed) used 3 counters for every loop. Justin improved it to
move 2 of those counters into the less-frequently executed breaks and continues,
but that turned out to produce wrong count values in some cases. The solution
requires visiting a loop body before the condition so that the count for the
condition properly includes the break and continue counts. Changing codegen to
visit a loop body first would be a fairly invasive change, but with a separate
AST traversal, it is easy to control the order of traversal. I've added a
testcase (provided by Justin) to make sure this works correctly.
3. It improves the instrumentation overhead, reducing the number of counters for
a loop from 3 to 1. We no longer need dedicated counters for breaks and
continues, since we can just use the propagated count values when visiting
breaks and continues.
To make this work, I needed to make a change to the way we count case
statements, going back to my original approach of not including the fall-through
in the counter values. This was necessary because there isn't always an AST node
that can be used to record the fall-through count. Now case statements are
handled the same as default statements, with the fall-through paths branching
over the counter increments. While I was at it, I also went back to using this
approach for do-loops -- omitting the fall-through count into the loop body
simplifies some of the calculations and make them behave the same as other
loops. Whenever we start using this instrumentation for coverage, we'll need
to add the fall-through counts into the counter values.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201528 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes PR15768, where the sret parameter and the 'this' parameter
are in the wrong order.
Instance methods compiled by MSVC never return records in registers,
they always return indirectly through an sret pointer. That sret
pointer always comes after the 'this' parameter, for both __cdecl and
__thiscall methods.
Unfortunately, the same is true for other calling conventions, so we'll
have to change the overall approach here relatively soon.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2664
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200587 91177308-0d34-0410-b5e6-96231b3b80d8
Due to statement expressions supported as GCC extension, it is possible
to put 'break' or 'continue' into a loop/switch statement but outside
its body, for example:
for ( ; ({ if (first) { first = 0; continue; } 0; }); )
This code is rejected by GCC if compiled in C mode but is accepted in C++
code. GCC bug 44715 tracks this discrepancy. Clang used code generation
that differs from GCC in both modes: only statement of the third
expression of 'for' behaves as if it was inside loop body.
This change makes code generation more close to GCC, considering 'break'
or 'continue' statement in condition and increment expressions of a
loop as it was inside the loop body. It also adds error for the cases
when 'break'/'continue' appear outside loop due to this syntax. If
code generation differ from GCC, warning is issued.
Differential Revision: http://llvm-reviews.chandlerc.com/D2518
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199897 91177308-0d34-0410-b5e6-96231b3b80d8
I misunderstood the discussion on this. The complexity here is
justified by the malloc overhead it saves.
This reverts commit r199302.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199700 91177308-0d34-0410-b5e6-96231b3b80d8
Way back in r129652 we tried to avoid emitting an empty block at -O0
for switch cases that did nothing but break. This led to a poor
debugging experience as reported in PR9796, so we disabled the
optimization for -O0 but left it in for higher optimization levels in
r154420.
Since the whole point of this was to improve -O0, it's silly to keep
the complexity at all.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199302 91177308-0d34-0410-b5e6-96231b3b80d8
adjustFallThroughCount isn't a good name, and the documentation was
even worse. This commit attempts to clarify what it's for and when to
use it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199139 91177308-0d34-0410-b5e6-96231b3b80d8
There are a number of places where we do PGO.setCurrentRegionCount(0)
directly after an unconditional branch. Give this operation a name so
that it's clearer why we're doing this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199138 91177308-0d34-0410-b5e6-96231b3b80d8
This call looks like it was an artifact of an earlier change, and
doesn't actually make sense. We begin a new region immediately anyway,
so it was mostly harmless.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199137 91177308-0d34-0410-b5e6-96231b3b80d8
C and C++ don't emit an extra lexical scope for the compound statement
that is the body of an Objective-C method.
rdar://problem/15010825
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198699 91177308-0d34-0410-b5e6-96231b3b80d8
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198686 91177308-0d34-0410-b5e6-96231b3b80d8
the lexical block formed by the compound statement that is the function
body.
rdar://problem/15010825
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198461 91177308-0d34-0410-b5e6-96231b3b80d8
This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities in nearby lines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196466 91177308-0d34-0410-b5e6-96231b3b80d8
Not long ago I made the CodeGen of for loops simplify the condition at
-O0 in the same way we do for if and conditionals. Unfortunately this
ties how loops and simple conditions work together too tightly, which
makes features such as instrumentation based PGO awkward.
Ultimately, we should find a more general way to simplify the logic in
a given condition, but for now we'll just avoid using EmitBranchOnBool
for loops, like we already do for while and do loops.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195438 91177308-0d34-0410-b5e6-96231b3b80d8
A while ago EmitForStmt was changed to explicitly evaluate the
condition expression and create a branch instead of using
EmitBranchOnBool, so that the condition expression could be used for
some cleanup logic. The cleanup stuff has since been reorganized, and
this is no longer necessary.
In EmitCXXForRange, the evaluated condition was never used for
anything else. The logic was presumably modeled on EmitForStmt.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193994 91177308-0d34-0410-b5e6-96231b3b80d8
An initialization somehow found its way in between a comment and the
block of code the comment is about. Moving the initialization makes
this less confusing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193993 91177308-0d34-0410-b5e6-96231b3b80d8
Currently we silently omit the code in the try and finally bodies, which
is pretty bad. This way we fail loudly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190809 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGenFunction is run on only one function - a new object is made for
each new function. I would add an assertion/flag to this effect, but
there's an exception: ObjC properties involve emitting helper functions
that are all emitted by the same CodeGenFunction object, so such a check
is not possible/correct.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189277 91177308-0d34-0410-b5e6-96231b3b80d8
between a block assignment and the entry of the block function. In reality
this wouldn't work anyway because blocks are predominantly created
on-the-fly inside of an ObjC method invocation.
The proper fix for the ambiguity is to use -gcolumn-info to differentiate
the breakpoints.
This is expected to break some block-related darwin-gdb tests.
rdar://problem/14039866
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184157 91177308-0d34-0410-b5e6-96231b3b80d8
declarations of reference type; they're handled by the general case handling of
MaterializeTemporaryExpr.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183875 91177308-0d34-0410-b5e6-96231b3b80d8
Two variables with the same name declared in two if conditions in the same
scope are no longer coalesced into one.
rdar://problem/14024005
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183597 91177308-0d34-0410-b5e6-96231b3b80d8
X86's 'y' inline assembly constraint represents an MMX register, this change
prevents Clang from hitting an assertion when passed an incompatible type to
deal with.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183467 91177308-0d34-0410-b5e6-96231b3b80d8
EmitCapturedStmt creates a captured struct containing all of the captured
variables, and then emits a call to the outlined function. This is similar in
principle to EmitBlockLiteral.
GenerateCapturedFunction actually produces the outlined function. It is based
on GenerateBlockFunction, but is much simpler. The function type is determined
by the parameters that are in the CapturedDecl.
Some changes have been added to this patch that were reviewed as part of the
serialization patch and moving the parameters to the captured decl.
Differential Revision: http://llvm-reviews.chandlerc.com/D640
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181536 91177308-0d34-0410-b5e6-96231b3b80d8
Un-break the gdb buildbot.
- Use the debug location of the return expression for the cleanup code
if the return expression is trivially evaluatable, regardless of the
number of stop points in the function.
- Ensure that any EH code in the cleanup still gets the line number of
the closing } of the lexical scope.
- Added a testcase with EH in the cleanup.
rdar://problem/13442648
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181056 91177308-0d34-0410-b5e6-96231b3b80d8
- Use the debug location of the return expression for the cleanup code
if the return expression is trivially evaluatable, regardless of the
number of stop points in the function.
- Ensure that any EH code in the cleanup still gets the line number of
the closing } of the lexical scope.
- Added a testcase with EH in the cleanup.
rdar://problem/13442648
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180982 91177308-0d34-0410-b5e6-96231b3b80d8
the actual parser and support arbitrary id-expressions.
We're actually basically set up to do arbitrary expressions here
if we wanted to.
Assembly operands permit things like A::x to be written regardless
of language mode, which forces us to embellish the evaluation
context logic somewhat. The logic here under template instantiation
is incorrect; we need to preserve the fact that an expression was
unevaluated. Of course, template instantiation in general is fishy
here because we have no way of delaying semantic analysis in the
MC parser. It's all just fishy.
I've also fixed the serialization of MS asm statements.
This commit depends on an LLVM commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180976 91177308-0d34-0410-b5e6-96231b3b80d8
If there is cleanup code, the cleanup code gets the debug location of
the closing '}'. The subsequent ret IR-instruction does not get a
debug location. The return _expression_ will get the debug location
of the return statement.
If the function contains only a single, simple return statement,
the cleanup code may become the first breakpoint in the function.
In this case we set the debug location for the cleanup code
to the location of the return statement.
rdar://problem/13442648
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180932 91177308-0d34-0410-b5e6-96231b3b80d8
aggregate types in a profoundly wrong way that has to be
worked around in every call site, to getEvaluationKind,
which classifies and distinguishes between all of these
cases.
Also, normalize the API for loading and storing complexes.
I'm working on a larger patch and wanted to pull these
changes out, but it would have be annoying to detangle
them from each other.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176656 91177308-0d34-0410-b5e6-96231b3b80d8
One of the gotchas (see changes to CodeGenFunction) was due to the fix in
r139416 (for PR10829). This only worked previously because the top level
lexical block would set the location to the end of the function, the debug
location would be updated (as per r139416), the location would be set to
the end of the function again (but that would no-op, since it was the same
as the previous location), then the return instruction would be emitted using
the debug location.
Once the top level lexical block was no longer emitted, the end-of-function
location change was causing the debug loc to be updated, regressing that bug.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173593 91177308-0d34-0410-b5e6-96231b3b80d8
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
Convert the uses of the Attributes class over to the new format. The
Attributes::get method call now takes an LLVM context so that the attributes
object can be uniquified and stored.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165918 91177308-0d34-0410-b5e6-96231b3b80d8
into the enclosing scope; this is a more accurate model but is
(I believe) unnecessary in my test case due to other flaws.
However, one of those flaws is now intentional: blocks which
appear in return statements can be trivially observed to not
extend in lifetime past the return, and so we can allow a jump
past them. Do the necessary magic in IR-generation to make
this work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164589 91177308-0d34-0410-b5e6-96231b3b80d8
implementation does not co-exist well with how the sideeffect and alignstack
attributes are handled.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163173 91177308-0d34-0410-b5e6-96231b3b80d8
AsmStmts. This function is only used by GCCAsmStmts, however. Constraints need
to be properly computed before MSAsmStmts can use EmitAsmStmt. No functional
change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162776 91177308-0d34-0410-b5e6-96231b3b80d8
coding standards. Also, add stub for MSAsmStmt class as part of unifying
codegen logic for AsmStmts.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162696 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGen option to a LangOpt option. In turn, hoist the guard into the parser
so that we avoid the new (and fairly unstable) Sema/AST/CodeGen logic. This
should restore the behavior of clang to that prior to r158325.
<rdar://problem/12163681>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162602 91177308-0d34-0410-b5e6-96231b3b80d8
The parser still can't handle all cases, so fall back to emitting a simple
MSAsmStmt if we get into trouble.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162382 91177308-0d34-0410-b5e6-96231b3b80d8
error was asserting on anything that included Windows.h. MS-style inline asm is
still dropped, but at least now we're not completely silent about it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158833 91177308-0d34-0410-b5e6-96231b3b80d8
Justin Bogner