| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
llvm-svn: 180982
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 180976
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 180932
|
|
|
|
|
|
| |
Patch by Stephen Lin!
llvm-svn: 179638
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CapturedStmt can be used to implement generic function outlining as described in
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-January/027540.html.
CapturedStmt is not exposed to the C api.
Serialization and template support are pending.
Author: Wei Pan <wei.pan@intel.com>
Differential Revision: http://llvm-reviews.chandlerc.com/D370
llvm-svn: 179615
|
|
|
|
|
|
| |
It is unused since pic support went away.
llvm-svn: 178055
|
|
|
|
|
|
|
|
|
| |
a more aggressive stack coloring.
Patch by John McCall with help by Shuxin Yang.
rdar://13115369
llvm-svn: 177819
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 176656
|
|
|
|
| |
llvm-svn: 176398
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 173593
|
|
|
|
|
|
|
|
| |
reflect the migration in r171366.
Re-sort the #include lines to reflect the new paths.
llvm-svn: 171369
|
|
|
|
| |
llvm-svn: 170722
|
|
|
|
|
|
| |
which is wrong here.
llvm-svn: 170721
|
|
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170500
|
|
|
|
|
|
| |
in the near future.
llvm-svn: 169652
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 169237
|
|
|
|
| |
llvm-svn: 166924
|
|
|
|
| |
llvm-svn: 166832
|
|
|
|
|
|
| |
simplify the code a bit. No functionality change.
llvm-svn: 166010
|
|
|
|
|
|
| |
own class named AttrBuilder. No functionality change.
llvm-svn: 165961
|
|
|
|
| |
llvm-svn: 165925
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 165918
|
|
|
|
|
|
|
| |
namespace. Use the attribute's enum value instead. No functionality change
intended.
llvm-svn: 165611
|
|
|
|
| |
llvm-svn: 165395
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 164589
|
|
|
|
| |
llvm-svn: 163232
|
|
|
|
| |
llvm-svn: 163178
|
|
|
|
|
|
|
| |
implementation does not co-exist well with how the sideeffect and alignstack
attributes are handled.
llvm-svn: 163173
|
|
|
|
| |
llvm-svn: 163161
|
|
|
|
| |
llvm-svn: 163149
|
|
|
|
|
|
| |
Also a minor fix to __except printing in StmtPrinter.cpp. Thanks to Aaron Ballman for review.
llvm-svn: 163083
|
|
|
|
| |
llvm-svn: 162796
|
|
|
|
|
|
|
|
| |
AsmStmts. This function is only used by GCCAsmStmts, however. Constraints need
to be properly computed before MSAsmStmts can use EmitAsmStmt. No functional
change intended.
llvm-svn: 162776
|
|
|
|
|
|
| |
More work towards unifying asm stmt codegen.
llvm-svn: 162712
|
|
|
|
|
|
| |
change intended.
llvm-svn: 162710
|
|
|
|
|
|
|
| |
coding standards. Also, add stub for MSAsmStmt class as part of unifying
codegen logic for AsmStmts.
llvm-svn: 162696
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 162632
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 162602
|
|
|
|
| |
llvm-svn: 162575
|
|
|
|
| |
llvm-svn: 162568
|
|
|
|
|
|
| |
ms-style inline asms.
llvm-svn: 162463
|
|
|
|
|
|
|
| |
The parser still can't handle all cases, so fall back to emitting a simple
MSAsmStmt if we get into trouble.
llvm-svn: 162382
|
|
|
|
|
|
|
| |
This is a reapplication of r161914 now that the scoping issue has been resolved
in r161966.
llvm-svn: 161967
|
|
|
|
| |
llvm-svn: 161931
|
|
|
|
| |
llvm-svn: 161914
|
|
|
|
| |
llvm-svn: 161642
|
|
|
|
|
|
| |
only machine specific clobbers are modeled.
llvm-svn: 161524
|
|
|
|
|
|
| |
APSInt::isSameValue() when comparing different sized APSInt's.
llvm-svn: 160641
|
|
|
|
| |
llvm-svn: 160580
|
|
|
|
|
|
|
| |
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.
llvm-svn: 158833
|