summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Propagate SourceLocations through to get a Loc on float_cast_overflowFilipe Cabecinhas2015-08-111-2/+4
| | | | | | | | | | | | | | | Summary: float_cast_overflow is the only UBSan check without a source location attached. This patch propagates SourceLocations where necessary to get them to the EmitCheck() call. Reviewers: rsmith, ABataev, rjmccall Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11757 llvm-svn: 244568
* [CodeGen] Simplify creation of shuffle masks.Benjamin Kramer2015-07-281-33/+8
| | | | | | No functional change intended. llvm-svn: 243439
* Pass an iterator range to EmitCallArgsDavid Blaikie2015-07-211-2/+2
| | | | llvm-svn: 242824
* Rely on default zero-arg value for IRBuilder::CreateCall calls to zero-arg ↵David Blaikie2015-07-141-2/+1
| | | | | | | | functions Patch by servuswiegehtz at yahoo.de llvm-svn: 242168
* Respect alignment of nested bitfieldsUlrich Weigand2015-07-101-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tools/clang/test/CodeGen/packed-nest-unpacked.c contains this test: struct XBitfield { unsigned b1 : 10; unsigned b2 : 12; unsigned b3 : 10; }; struct YBitfield { char x; struct XBitfield y; } __attribute((packed)); struct YBitfield gbitfield; unsigned test7() { // CHECK: @test7 // CHECK: load i32, i32* getelementptr inbounds (%struct.YBitfield, %struct.YBitfield* @gbitfield, i32 0, i32 1, i32 0), align 4 return gbitfield.y.b2; } The "align 4" is actually wrong. Accessing all of "gbitfield.y" as a single i32 is of course possible, but that still doesn't make it 4-byte aligned as it remains packed at offset 1 in the surrounding gbitfield object. This alignment was changed by commit r169489, which also introduced changes to bitfield access code in CGExpr.cpp. Code before that change used to take into account *both* the alignment of the field to be accessed within the current struct, *and* the alignment of that outer struct itself; this logic was removed by the above commit. Neglecting to consider both values can cause incorrect code to be generated (I've seen an unaligned access crash on SystemZ due to this bug). In order to always use the best known alignment value, this patch removes the CGBitFieldInfo::StorageAlignment member and replaces it with a StorageOffset member specifying the offset from the start of the surrounding struct to the bitfield's underlying storage. This offset can then be combined with the best-known alignment for a bitfield access lvalue to determine the alignment to use when accessing the bitfield's storage. Differential Revision: http://reviews.llvm.org/D11034 llvm-svn: 241916
* Attach attribute "trap-func-name" to call sites of llvm.trap and llvm.debugtrap.Akira Hatanaka2015-07-021-2/+13
| | | | | | | | | | | This is needed to use clang's command line option "-ftrap-function" for LTO and enable changing the trap function name on a per-call-site basis. rdar://problem/21225723 Differential Revision: http://reviews.llvm.org/D10831 llvm-svn: 241306
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-1/+1
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-1/+1
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* Implement diagnostic mode for -fsanitize=cfi*, -fsanitize=cfi-diag.Peter Collingbourne2015-06-191-2/+4
| | | | | | | | | | | | | | | | | This causes programs compiled with this flag to print a diagnostic when a control flow integrity check fails instead of aborting. Diagnostics are printed using UBSan's runtime library. The main motivation of this feature over -fsanitize=vptr is fidelity with the -fsanitize=cfi implementation: the diagnostics are printed under exactly the same conditions as those which would cause -fsanitize=cfi to abort the program. This means that the same restrictions apply regarding compiling all translation units with -fsanitize=cfi, cross-DSO virtual calls are forbidden, etc. Differential Revision: http://reviews.llvm.org/D10268 llvm-svn: 240109
* Introduce -fsanitize-trap= flag.Peter Collingbourne2015-06-181-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error has been made an alias of -fsanitize-trap=undefined. This change also cleans up some awkward behavior around the combination of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we would reject command lines containing the combination of these two flags, as -fsanitize=vptr is not compatible with trapping. This required the creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr (and -fsanitize=function, but this seems like an oversight). Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap, and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr as an "unsupported" flag, which means that we error out if the flag is specified explicitly, but implicitly disable it if the flag was implied by -fsanitize=undefined. Differential Revision: http://reviews.llvm.org/D10464 llvm-svn: 240105
* API update for streamlining of IRBuilder::CreateCall to just use ↵David Blaikie2015-05-181-4/+4
| | | | | | ArrayRef/initializer_list+braced init llvm-svn: 237625
* Unify sanitizer kind representation between the driver and the rest of the ↵Peter Collingbourne2015-05-111-4/+6
| | | | | | | | | | compiler. No functional change. Differential Revision: http://reviews.llvm.org/D9618 llvm-svn: 237055
* InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC)Justin Bogner2015-04-231-4/+3
| | | | | | | | | The RegionCounter type does a lot of legwork, but most of it is only meaningful within the implementation of CodeGenPGO. The uses elsewhere in CodeGen generally just want to increment or read counters, so do that directly. llvm-svn: 235664
* [CodeGen] Do a more principled fix for PR231653, always use the inner type.Benjamin Kramer2015-04-091-10/+9
| | | | | | | We were still using the MaterializeTemporaryExpr's type to check if the transform is legal. Always use the inner Expr type. llvm-svn: 234543
* [CodeGen] When promoting a reference temporary to a global use the inner ↵Benjamin Kramer2015-04-091-3/+4
| | | | | | | | | type to fold it. The MaterializeTemporaryExpr can have a different type than the inner expression, miscompiling the constant. PR23165. llvm-svn: 234499
* clang-format my last commitDavid Blaikie2015-04-051-3/+2
| | | | | | (sorry, keep forgetting that) llvm-svn: 234129
* [opaque pointer type] More GEP API migrationsDavid Blaikie2015-04-051-4/+4
| | | | | | | Looks like the VTable code in particular will need some work to pass around the pointee type explicitly. llvm-svn: 234128
* [opaque pointer type] More GEP API migrationsDavid Blaikie2015-04-041-2/+2
| | | | llvm-svn: 234109
* Fix the LLVM type used when lowering initializer list reference temporaries ↵Nick Lewycky2015-03-181-2/+5
| | | | | | to global variables. Reapplies r232454 with fix for PR22940. llvm-svn: 232579
* Revert r232454 and r232456: "Fix the LLVM type used when lowering ↵Hans Wennborg2015-03-171-5/+2
| | | | | | | | initializer list reference temporaries to global variables." This caused PR22940. llvm-svn: 232496
* Fix the LLVM type used when lowering initializer list reference temporaries ↵Nick Lewycky2015-03-171-2/+5
| | | | | | to global variables. llvm-svn: 232454
* Implement bad cast checks using control flow integrity information.Peter Collingbourne2015-03-141-0/+7
| | | | | | | | | | | This scheme checks that pointer and lvalue casts are made to an object of the correct dynamic type; that is, the dynamic type of the object must be a derived class of the pointee type of the cast. The checks are currently only introduced where the class being casted to is a polymorphic class. Differential Revision: http://reviews.llvm.org/D8312 llvm-svn: 232241
* Reapply r231508 "CodeGen: Emit constant temporaries into read-only globals."Benjamin Kramer2015-03-071-2/+20
| | | | | | | | | | | | I disabled putting the new global into the same COMDAT as the function for now. There's a fundamental problem when we inline references to the global but still have the global in a COMDAT linked to the inlined function. Since this is only an optimization there may be other versions of the COMDAT around that are missing the new global and hell breaks loose at link time. I hope the chromium build doesn't break this time :) llvm-svn: 231564
* Revert r231508 "CodeGen: Emit constant temporaries into read-only globals."Hans Wennborg2015-03-071-22/+2
| | | | | | | | | This broke the Chromium build. Links were failing with messages like: obj/dbus/libdbus_test_support.a(obj/dbus/dbus_test_support.mock_object_proxy.o):../../dbus/mock_object_proxy.cc:function dbus::MockObjectProxy::Detach(): warning: relocation refers to discarded section /usr/local/google/work/chromium/src/third_party/binutils/Linux_x64/Release/bin/ld.gold: error: treating warnings as errors llvm-svn: 231541
* CodeGen: Emit constant temporaries into read-only globals.Benjamin Kramer2015-03-061-2/+22
| | | | | | | | | | | | | | | | | | | | | | | Instead of creating a copy on the stack just stash them in a private constant global. This saves both the copying overhead and the stack space, and gives the optimizer more room to constant fold. This tries to make array temporaries more similar to regular arrays, they can't use the same logic because a temporary has no VarDecl to be bound to so we roll our own version here. The original use case for this optimization was code like for (int i : {1, 2, 3, 4, 5, 6, 7, 8, 10}) foo(i); where without this patch (assuming that the loop is not unrolled) we would alloca an array on the stack, copy the 10 values over and iterate on that. With this patch we put the array in .text use it directly. Apart from that case this helps on virtually any passing of a constant std::initializer_list as a function argument. Differential Revision: http://reviews.llvm.org/D8034 llvm-svn: 231508
* Sema: Parenthesized bound destructor member expressions can be calledDavid Majnemer2015-02-251-1/+1
| | | | | | | | | We would wrongfully reject (a.~A)() in both the destructor and pseudo-destructor cases. This fixes PR22668. llvm-svn: 230512
* [OPENMP] Rename methods of OpenMPRuntime class. NFC. Alexey Bataev2015-02-251-1/+1
| | | | llvm-svn: 230470
* Try to unbreak the Hexagon botDavid Majnemer2015-02-141-1/+1
| | | | llvm-svn: 229219
* CodeGen: _Atomic(_Complex) shouldn't crashDavid Majnemer2015-02-141-2/+6
| | | | | | | We could be a little kinder if we did a compare-exchange loop instead of an atomic-load/store pair. llvm-svn: 229212
* Revert "Revert r229082 for a bit, it caused PR22577."David Majnemer2015-02-141-2/+3
| | | | | | | This reverts commit r229123. It was a red herring, the bug was present without r229082. llvm-svn: 229205
* CodeGen: Correctly convert atomic bool from i8 to i1David Majnemer2015-02-141-1/+1
| | | | | | | | | Bools are a little tricky, they are i8 in memory and must be coerced back to i1 before further operations can be performed on them. This fixes PR22577. llvm-svn: 229204
* Revert r229082 for a bit, it caused PR22577.Nico Weber2015-02-131-3/+2
| | | | llvm-svn: 229123
* MS ABI: Implement /volatile:msDavid Majnemer2015-02-131-2/+3
| | | | | | | | | | | | The /volatile:ms semantics turn volatile loads and stores into atomic acquire and release operations. This distinction is important because volatile memory operations do not form a happens-before relationship with non-atomic memory. This means that a volatile store is not sufficient for implementing a mutex unlock routine. Differential Revision: http://reviews.llvm.org/D7580 llvm-svn: 229082
* DebugInfo: Attribute calls to overloaded operators with the operator, not ↵David Blaikie2015-01-251-2/+0
| | | | | | the start of the whole expression llvm-svn: 227028
* DebugInfo: Use the preferred location rather than the start location for ↵David Blaikie2015-01-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expression line info This causes things like assignment to refer to the '=' rather than the LHS when attributing the store instruction, for example. There were essentially 3 options for this: * The beginning of an expression (this was the behavior prior to this commit). This meant that stepping through subexpressions would bounce around from subexpressions back to the start of the outer expression, etc. (eg: x + y + z would go x, y, x, z, x (the repeated 'x's would be where the actual addition occurred)). * The end of an expression. This seems to be what GCC does /mostly/, and certainly this for function calls. This has the advantage that progress is always 'forwards' (never jumping backwards - except for independent subexpressions if they're evaluated in interesting orders, etc). "x + y + z" would go "x y z" with the additions occurring at y and z after the respective loads. The problem with this is that the user would still have to think fairly hard about precedence to realize which subexpression is being evaluated or which operator overload is being called in, say, an asan backtrace. * The preferred location or 'exprloc'. In this case you get sort of what you'd expect, though it's a bit confusing in its own way due to going 'backwards'. In this case the locations would be: "x y + z +" in lovely postfix arithmetic order. But this does mean that if the op+ were an operator overload, say, and in a backtrace, the backtrace will point to the exact '+' that's being called, not to the end of one of its operands. (actually the operator overload case doesn't work yet for other reasons, but that's being fixed - but this at least gets scalar/complex assignments and other plain operators right) llvm-svn: 227027
* DebugInfo: Correct the line location of geps on array accessesDavid Blaikie2015-01-241-0/+1
| | | | llvm-svn: 227023
* DebugInfo: Remove outdated comment. Column info is no longer needed to ↵David Blaikie2015-01-231-6/+0
| | | | | | differentiate inline callsites. llvm-svn: 226955
* DebugInfo: Remove forced column-info workaround for inlined callsDavid Blaikie2015-01-211-15/+2
| | | | | | | | | | | | | | | | | This workaround was to provide unique call sites to ensure LLVM's inline debug info handling would properly unique two calls to the same function on the same line. Instead, this has now been fixed in LLVM (r226736) and the workaround here can be removed. Originally committed in r176895, but this isn't a straight revert due to all the changes since then. I just searched for anything ForcedColumn* related and removed them. We could test this - but it didn't strike me as terribly valuable once we're no longer adding this workaround everything just works as expected & it's no longer a special case to test for. llvm-svn: 226738
* [cleanup] Re-sort *all* #include lines with llvm/utils/sort_includes.pyChandler Carruth2015-01-141-1/+1
| | | | | | | | | | Sorry for the noise, I managed to miss a bunch of recent regressions of include orderings here. This should actually sort all the includes for Clang. Again, no functionality changed, this is just a mechanical cleanup that I try to run periodically to keep the #include lines as regular as possible across the project. llvm-svn: 225979
* Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info ↵David Blaikie2015-01-141-27/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | location handling (and follow-up commits). Several pieces of code were relying on implicit debug location setting which usually lead to incorrect line information anyway. So I've fixed those (in r225955 and r225845) separately which should pave the way for this commit to be cleanly reapplied. The reason these implicit dependencies resulted in crashes with this patch is that the debug location would no longer implicitly leak from one place to another, but be set back to invalid. Once a call with no/invalid location was emitted, if that call was ever inlined it could produce invalid debugloc chains and assert during LLVM's codegen. There may be further cases of such bugs in this patch - they're hard to flush out with regression testing, so I'll keep an eye out for reports and investigate/fix them ASAP if they come up. Original commit message: Reapply "DebugInfo: Generalize debug info location handling" Originally committed in r224385 and reverted in r224441 due to concerns this change might've introduced a crash. Turns out this change fixes the crash introduced by one of my earlier more specific location handling changes (those specific fixes are reverted by this patch, in favor of the more general solution). Recommitted in r224941 and reverted in r224970 after it caused a crash when building compiler-rt. Looks to be due to this change zeroing out the debug location when emitting default arguments (which were meant to inherit their outer expression's location) thus creating call instructions without locations - these create problems for inlining and must not be created. That is fixed and tested in this version of the change. Original commit message: This is a more scalable (fixed in mostly one place, rather than many places that will need constant improvement/maintenance) solution to several commits I've made recently to increase source fidelity for subexpressions. This resetting had to be done at the DebugLoc level (not the SourceLocation level) to preserve scoping information (if the resetting was done with CGDebugInfo::EmitLocation, it would've caused the tail end of an expression's codegen to end up in a potentially different scope than the start, even though it was at the same source location). The drawback to this is that it might leave CGDebugInfo out of sync. Ideally CGDebugInfo shouldn't have a duplicate sense of the current SourceLocation, but for now it seems it does... - I don't think I'm going to tackle removing that just now. I expect this'll probably cause some more buildbot fallout & I'll investigate that as it comes up. Also these sort of improvements might be starting to show a weakness/bug in LLVM's line table handling: we don't correctly emit is_stmt for statements, we just put it on every line table entry. This means one statement split over multiple lines appears as multiple 'statements' and two statements on one line (without column info) are treated as one statement. I don't think we have any IR representation of statements that would help us distinguish these cases and identify the beginning of each statement - so that might be something we need to add (possibly to the lexical scope chain - a scope for each statement). This does cause some problems for GDB and possibly other DWARF consumers. llvm-svn: 225956
* Reimplement -fsanitize-recover family of flags.Alexey Samsonov2015-01-121-38/+85
| | | | | | | | | | | | | | | | | | | | | | | | Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
* Rename RefersToCapturedVariable to RefersToEnclosingVariableOrCapture, NFCAlexey Bataev2015-01-121-1/+1
| | | | llvm-svn: 225624
* Revert "DebugInfo: Generalize debug info location handling" and related commitsDavid Blaikie2015-01-091-10/+27
| | | | | | | | | | | | This reverts commit r225000, r225021, r225083, r225086, r225090. The root change (r225000) still has several issues where it's caused calls to be emitted without debug locations. This causes assertion failures if/when those calls are inlined. I'll work up some test cases and fixes before recommitting this. llvm-svn: 225555
* CodeGen: Don't crash when a lambda uses a local constexpr variableDavid Majnemer2015-01-011-16/+16
| | | | | | | | | | | The DeclRefExpr might be for a variable initialized by a constant expression which hasn't been ODR used. Emit the initializer for the variable instead of trying to capture the variable itself. This fixes PR22071. llvm-svn: 225060
* Reapply "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-301-27/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally committed in r224385 and reverted in r224441 due to concerns this change might've introduced a crash. Turns out this change fixes the crash introduced by one of my earlier more specific location handling changes (those specific fixes are reverted by this patch, in favor of the more general solution). Recommitted in r224941 and reverted in r224970 after it caused a crash when building compiler-rt. Looks to be due to this change zeroing out the debug location when emitting default arguments (which were meant to inherit their outer expression's location) thus creating call instructions without locations - these create problems for inlining and must not be created. That is fixed and tested in this version of the change. Original commit message: This is a more scalable (fixed in mostly one place, rather than many places that will need constant improvement/maintenance) solution to several commits I've made recently to increase source fidelity for subexpressions. This resetting had to be done at the DebugLoc level (not the SourceLocation level) to preserve scoping information (if the resetting was done with CGDebugInfo::EmitLocation, it would've caused the tail end of an expression's codegen to end up in a potentially different scope than the start, even though it was at the same source location). The drawback to this is that it might leave CGDebugInfo out of sync. Ideally CGDebugInfo shouldn't have a duplicate sense of the current SourceLocation, but for now it seems it does... - I don't think I'm going to tackle removing that just now. I expect this'll probably cause some more buildbot fallout & I'll investigate that as it comes up. Also these sort of improvements might be starting to show a weakness/bug in LLVM's line table handling: we don't correctly emit is_stmt for statements, we just put it on every line table entry. This means one statement split over multiple lines appears as multiple 'statements' and two statements on one line (without column info) are treated as one statement. I don't think we have any IR representation of statements that would help us distinguish these cases and identify the beginning of each statement - so that might be something we need to add (possibly to the lexical scope chain - a scope for each statement). This does cause some problems for GDB and possibly other DWARF consumers. llvm-svn: 225000
* Revert "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-291-10/+27
| | | | | | | | | Asserting when building compiler-rt when using a GCC host compiler. Reverting while I investigate. This reverts commit r224941. llvm-svn: 224970
* Reapply "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-291-27/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally committed in r224385 and reverted in r224441 due to concerns this change might've introduced a crash. Turns out this change fixes the crash introduced by one of my earlier more specific location handling changes (those specific fixes are reverted by this patch, in favor of the more general solution). Original commit message: This is a more scalable (fixed in mostly one place, rather than many places that will need constant improvement/maintenance) solution to several commits I've made recently to increase source fidelity for subexpressions. This resetting had to be done at the DebugLoc level (not the SourceLocation level) to preserve scoping information (if the resetting was done with CGDebugInfo::EmitLocation, it would've caused the tail end of an expression's codegen to end up in a potentially different scope than the start, even though it was at the same source location). The drawback to this is that it might leave CGDebugInfo out of sync. Ideally CGDebugInfo shouldn't have a duplicate sense of the current SourceLocation, but for now it seems it does... - I don't think I'm going to tackle removing that just now. I expect this'll probably cause some more buildbot fallout & I'll investigate that as it comes up. Also these sort of improvements might be starting to show a weakness/bug in LLVM's line table handling: we don't correctly emit is_stmt for statements, we just put it on every line table entry. This means one statement split over multiple lines appears as multiple 'statements' and two statements on one line (without column info) are treated as one statement. I don't think we have any IR representation of statements that would help us distinguish these cases and identify the beginning of each statement - so that might be something we need to add (possibly to the lexical scope chain - a scope for each statement). This does cause some problems for GDB and possibly other DWARF consumers. llvm-svn: 224941
* Revert "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-171-10/+27
| | | | | | | | | Fails an ASan bootstrap - I'll try to reproduce locally & sort that out before recommitting. This reverts commit r224385. llvm-svn: 224441
* DebugInfo: Generalize debug info location handlingDavid Blaikie2014-12-161-27/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a more scalable (fixed in mostly one place, rather than many places that will need constant improvement/maintenance) solution to several commits I've made recently to increase source fidelity for subexpressions. This resetting had to be done at the DebugLoc level (not the SourceLocation level) to preserve scoping information (if the resetting was done with CGDebugInfo::EmitLocation, it would've caused the tail end of an expression's codegen to end up in a potentially different scope than the start, even though it was at the same source location). The drawback to this is that it might leave CGDebugInfo out of sync. Ideally CGDebugInfo shouldn't have a duplicate sense of the current SourceLocation, but for now it seems it does... - I don't think I'm going to tackle removing that just now. I expect this'll probably cause some more buildbot fallout & I'll investigate that as it comes up. Also these sort of improvements might be starting to show a weakness/bug in LLVM's line table handling: we don't correctly emit is_stmt for statements, we just put it on every line table entry. This means one statement split over multiple lines appears as multiple 'statements' and two statements on one line (without column info) are treated as one statement. I don't think we have any IR representation of statements that would help us distinguish these cases and identify the beginning of each statement - so that might be something we need to add (possibly to the lexical scope chain - a scope for each statement). This does cause some problems for GDB and possibly other DWARF consumers. llvm-svn: 224385
* Renamed RefersToEnclosingLocal bitfield to RefersToCapturedVariable.Alexey Bataev2014-12-161-4/+5
| | | | | | | Bitfield RefersToEnclosingLocal of Stmt::DeclRefExprBitfields renamed to RefersToCapturedVariable to reflect latest changes introduced in commit 224323. Also renamed method Expr::refersToEnclosingLocal() to Expr::refersToCapturedVariable() and comments for constant arguments. No functional changes. llvm-svn: 224329
OpenPOWER on IntegriCloud