summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGException.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC)Justin Bogner2015-04-231-4/+2
| | | | | | | | | 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
* [MS ABI] Use the right types for filter and finally blocksDavid Majnemer2015-04-171-4/+6
| | | | | | | The type for abnormal_termination can't be an i1, it an i8. Filter functions return 'LONG', not 'int'. llvm-svn: 235161
* Reland r234613 (and follow-ups 234614, 234616, 234618)Reid Kleckner2015-04-141-117/+148
| | | | | | | The frameescape intrinsic cannot be inlined, so I fixed the inliner in r234937. This should address PR23216. llvm-svn: 234942
* Revert r234613 (and follow-ups 234614, 234616, 234618), it caused PR23216.Nico Weber2015-04-131-148/+117
| | | | llvm-svn: 234789
* Revert r234786, it contained a bunch of stuff I did not mean to commit.Nico Weber2015-04-131-117/+148
| | | | llvm-svn: 234787
* Revert r234613 (and follow-ups 234614, 234616, 234618), it caused PR23216.Nico Weber2015-04-131-148/+117
| | | | llvm-svn: 234786
* [SEH] Re-land r234532, but use internal linkage for all SEH helpersReid Kleckner2015-04-101-117/+148
| | | | | | | | | | Even though these symbols are in a comdat group, the Microsoft linker really wants them to have internal linkage. I'm planning to tweak the mangling in a follow-up change. This is a straight revert with a 1-line fix. llvm-svn: 234613
* Revert r234532 for a bit, it very likely caused http://crbug.com/475768Nico Weber2015-04-101-146/+115
| | | | llvm-svn: 234563
* [SEH] Outline finally blocks using the new variable capture supportReid Kleckner2015-04-091-115/+146
| | | | | | | | | | | | | | | WinEHPrepare was going to have to pattern match the control flow merge and split that the old lowering used, and that wasn't really feasible. Now we can teach WinEHPrepare to pattern match this, which is much simpler: %fp = call i8* @llvm.frameaddress(i32 0) call void @func(iN [01], i8* %fp) This prototype happens to match the prototype used by the Win64 SEH personality function, so this is really simple. llvm-svn: 234532
* Reland "[SEH] Implement filter capturing in CodeGen"Reid Kleckner2015-04-081-20/+109
| | | | | | | | | | | The test should be fixed. It was failing in NDEBUG builds due to a missing '*' character in a regex. In asserts builds, the pattern matched a single digit value, which became a double digit value in NDEBUG builds. Go figure. This reverts commit r234261. llvm-svn: 234447
* Revert "[SEH] Implement filter capturing in CodeGen"Daniel Jasper2015-04-071-109/+20
| | | | | | | Test fails: http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check/3182/ llvm-svn: 234306
* [SEH] Implement filter capturing in CodeGenReid Kleckner2015-04-061-20/+109
| | | | | | | | | | | | | | | While capturing filters aren't very common, we'd like to outline __finally blocks in the frontend to simplify -O0 EH preparation and reduce code size. Finally blocks are usually have captures, and this is the first step towards that. Currently we don't support capturing 'this' or VLAs. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D8825 llvm-svn: 234261
* [opaque pointer type] More GEP API migrationsDavid Blaikie2015-04-051-1/+1
| | | | | | | Looks like the VTable code in particular will need some work to pass around the pointee type explicitly. llvm-svn: 234128
* [MS ABI] Disregard restrictive exception specificationsDavid Majnemer2015-04-011-0/+8
| | | | | | | | | | | MSVC treats all non-empty exception specifications the same way: all exceptions are permitted. The .xdata tables provide a way to efficiently lower exception specifications *but* this probably has to be implemented as a catch-all/rethrow mechanism instead of the Itanium way. This fixes PR23092. llvm-svn: 233787
* [MS ABI] Rework .xdata HandlerType emissionDavid Majnemer2015-03-291-1/+1
| | | | | | | | | | Utilizing IMAGEREL relocations for synthetic IR constructs isn't valuable, just clutter. While we are here, simplify HandlerType names by making the numeric value for the 'adjective' part of the mangled name instead of appending '.const', etc. The old scheme made for very long global names and leads to wordy things like '.std_bad_alloc' llvm-svn: 233503
* MS ABI: Emit HandlerMap entries for C++ catchDavid Majnemer2015-03-171-1/+2
| | | | | | | | | | | | | The HandlerMap describes, to the runtime, what sort of catches surround the try. In principle, this structure has to be emitted by the backend because only it knows the layout of the stack (the runtime needs to know where on the stack the destination of a copy lives, etc.) but there is some C++ specific information that the backend can't reason about. Stick this information in special LLVM globals with the relevant "const", "volatile", "reference" info mangled into the name. llvm-svn: 232538
* WIPDavid Majnemer2015-03-171-1/+1
| | | | llvm-svn: 232537
* MS ABI: Implement support for throwing a C++ exceptionDavid Majnemer2015-03-051-96/+18
| | | | | | | | | | | | | | | | | | | | | | | Throwing a C++ exception, under the MS ABI, is implemented using three components: - ThrowInfo structure which contains information like CV qualifiers, what destructor to call and a pointer to the CatchableTypeArray. - In a significant departure from the Itanium ABI, copying by-value occurs in the runtime and not at the catch site. This means we need to enumerate all possible types that this exception could be caught as and encode the necessary information to convert from the exception object's type to the catch handler's type. This includes complicated derived to base conversions and the execution of copy-constructors. N.B. This implementation doesn't support the execution of a copy-constructor from within the runtime for now. Adding support for that functionality is quite difficult due to things like default argument expressions which may evaluate arbitrary code hiding in the copy-constructor's parameters. Differential Revision: http://reviews.llvm.org/D8066 llvm-svn: 231328
* Split catch IRgen into ItaniumCXXABI and MicrosoftCXXABIReid Kleckner2015-03-031-381/+21
| | | | | | | | | Use llvm.eh.begincatch for Microsoft-style catches. This moves lots of CGException code into ItaniumCXXABI. Sorry for the blame pain. llvm-svn: 231105
* Don't crash on leaving nested __finally blocks through an EH edge.Nico Weber2015-02-261-19/+12
| | | | | | | | | | | | | | | The __finally emission block tries to be clever by removing unused continuation edges if there's an unconditional jump out of the __finally block. With exception edges, the EH continuation edge isn't always unused though and we'd crash in a few places. Just don't be clever. That makes the IR for __finally blocks a bit longer in some cases (hence small and behavior-preserving changes to existing tests), but it makes no difference in general and it fixes the last crash from PR22553. http://reviews.llvm.org/D7918 llvm-svn: 230697
* MS ABI: Turn throw into std::terminate for now, make try/catch "work"David Majnemer2015-02-251-7/+19
| | | | | | | This lets us compile programs which make use of exceptional constructs statically without executing any of them dynamically. llvm-svn: 230568
* Reland r230460 with a test fix for -Asserts builds.Nico Weber2015-02-251-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | Original CL description: Produce less broken basic block sequences for __finally blocks. The way cleanups (such as PerformSEHFinally) get emitted is that codegen generates some initialization code, then calls the cleanup's Emit() with the insertion point set to a good place, then the cleanup is supposed to emit its stuff, and then codegen might tack in a jump or similar to where the insertion point is after the cleanup. The PerformSEHFinally cleanup tries to just stash away the block it's supposed to codegen into, and then does codegen later, into that stashed block. However, after codegen'ing the __finally block, it used to set the insertion point to the finally's continuation block (where the __finally cleanup goes when its body is completed after regular, non-exceptional control flow). That's not correct, as that block can (and generally does) already ends in a jump. Instead, remember the insertion point that was current before the __finally got emitted, and restore that. Fixes two of the crashes in PR22553. llvm-svn: 230503
* Revert "Produce less broken basic block sequences for __finally blocks."Daniel Jasper2015-02-251-4/+3
| | | | | | | | | The test is broken on buildbots: http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check/2279/ This reverts commit adda738b6dc533c42db5f5f5b31344098a3aba7d. llvm-svn: 230472
* Produce less broken basic block sequences for __finally blocks.Nico Weber2015-02-251-3/+4
| | | | | | | | | | | | | | | | | | | | | The way cleanups (such as PerformSEHFinally) get emitted is that codegen generates some initialization code, then calls the cleanup's Emit() with the insertion point set to a good place, then the cleanup is supposed to emit its stuff, and then codegen might tack in a jump or similar to where the insertion point is after the cleanup. The PerformSEHFinally cleanup tries to just stash away the block it's supposed to codegen into, and then does codegen later, into that stashed block. However, after codegen'ing the __finally block, it used to set the insertion point to the finally's continuation block (where the __finally cleanup goes when its body is completed after regular, non-exceptional control flow). That's not correct, as that block can (and generally does) already ends in a jump. Instead, remember the insertion point that was current before the __finally got emitted, and restore that. Fixes two of the crashes in PR22553. llvm-svn: 230460
* SEH: Use the SEHTryEpilogueStack instead of a separate boolReid Kleckner2015-02-121-5/+2
| | | | | | We don't need a bool to track this now that we have a stack for it. llvm-svn: 228982
* [ms] Implement codegen for __leave.Nico Weber2015-02-121-1/+18
| | | | | | Reviewed at http://reviews.llvm.org/D7575 llvm-svn: 228977
* Wrap to 80 columns. No behavior change.Nico Weber2015-02-111-3/+5
| | | | llvm-svn: 228880
* Add the 'noinline' attribute to call sites within __try bodiesReid Kleckner2015-02-111-1/+6
| | | | | | | LLVM doesn't support non-call exceptions, so inlining makes it harder to catch such asynchronous exceptions. llvm-svn: 228876
* Add a comdat to __clang_call_terminateReid Kleckner2015-02-111-0/+2
| | | | llvm-svn: 228863
* Emit landing pads for SEH even if nounwind is presentReid Kleckner2015-02-111-2/+1
| | | | | | | Disabling exceptions applies nounwind to lots of functions. SEH catches asynch exceptions, so emit the landing pad anyway. llvm-svn: 228769
* Re-land r228258 and make clang-cl's /EHs- disable -fexceptions againReid Kleckner2015-02-051-24/+32
| | | | | | | | | | | After r228258, Clang started emitting C++ EH IR that LLVM wasn't ready to deal with, even when exceptions were disabled with /EHs-. This time, make /EHs- turn off -fexceptions while still emitting exceptional constructs in functions using __try. Since Sema rejects C++ exception handling constructs before CodeGen, landingpads should only appear in such functions as the result of a __try. llvm-svn: 228329
* Revert r228258.Nico Weber2015-02-051-22/+22
| | | | | | | | | It caused a chromium base unittest that tests throwing and catching SEH exceptions to fail (http://crbug.com/455488) and I suspect it might also be the cause of the chromium clang win 64-bit shared release builder timing out during compiles. So revert to see if that's true. llvm-svn: 228262
* Silence a warning.Sean Silva2015-02-051-1/+1
| | | | | | | | | /Users/Sean/pg/llvm/tools/clang/lib/CodeGen/CGException.cpp:1871:23: warning: unused variable 'Finally' [-Wunused-variable] if (SEHFinallyStmt *Finally = S.getFinallyHandler()) { ^ 1 warning generated. llvm-svn: 228255
* Fix crash on finally blocks that don't fall throughReid Kleckner2015-02-051-1/+9
| | | | llvm-svn: 228243
* Implement IRGen for SEH __finally and AbnormalTerminationReid Kleckner2015-02-041-12/+70
| | | | | | | | | | | Previously we would simply double-emit the body of the __finally block, but that doesn't work when it contains any kind of Decl, which we can't double emit. This fixes that by emitting the block once and branching into a shared code region and then branching back out. llvm-svn: 228222
* SEH: Track users of __try so we can pick a per-func EH personalityReid Kleckner2015-02-031-22/+22
| | | | | | | | | | | | | | | | | | There are four major kinds of declarations that cause code generation: - FunctionDecl (includes CXXMethodDecl etc) - ObjCMethodDecl - BlockDecl - CapturedDecl This patch tracks __try usage on FunctionDecls and diagnoses __try usage in other decls. If someone wants to use __try from ObjC, they can use it from a free function, since the ObjC code will need an ObjC-style EH personality. Eventually we will want to look through CapturedDecls and track SEH usage on the parent FunctionDecl, if present. llvm-svn: 228058
* Address review feedback for r228003.Adrian Prantl2015-02-031-1/+1
| | | | | | | - use named constructors - get rid of MarkAsPrologue llvm-svn: 228021
* Merge ArtificialLocation into ApplyDebugLocation and make a clearAdrian Prantl2015-02-031-1/+1
| | | | | | | | | | | | | | | | distinction between the different use-cases. With the previous default behavior we would occasionally emit empty debug locations in situations where they actually were strictly required (= on invoke insns). We now have a choice between defaulting to an empty location or an artificial location. Specifically, this fixes a bug caused by a missing debug location when emitting C++ EH cleanup blocks from within an artificial function, such as an ObjC destroy helper function. rdar://problem/19670595 llvm-svn: 228003
* SEH: Don't jump to an unreachable continuation blockReid Kleckner2015-01-301-1/+2
| | | | | | | If both the __try and __except blocks do not return, we want to delete the continuation block as unreachable instead. llvm-svn: 227627
* SEH: Emit the constant filter 1 as a catch-allReid Kleckner2015-01-221-0/+12
| | | | | | Minor optimization of code like __try { ... } __except(1) { ... }. llvm-svn: 226766
* Initial support for Win64 SEH IR emissionReid Kleckner2015-01-221-4/+251
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The lowering looks a lot like normal EH lowering, with the exception that the exceptions are caught by executing filter expression code instead of matching typeinfo globals. The filter expressions are outlined into functions which are used in landingpad clauses where typeinfo would normally go. Major aspects that still need work: - Non-call exceptions in __try bodies won't work yet. The plan is to outline the __try block in the frontend to keep things simple. - Filter expressions cannot use local variables until capturing is implemented. - __finally blocks will not run after exceptions. Fixing this requires work in the LLVM SEH preparation pass. The IR lowering looks like this: // C code: bool safe_div(int n, int d, int *r) { __try { *r = normal_div(n, d); } __except(_exception_code() == EXCEPTION_INT_DIVIDE_BY_ZERO) { return false; } return true; } ; LLVM IR: define i32 @filter(i8* %e, i8* %fp) { %ehptrs = bitcast i8* %e to i32** %ehrec = load i32** %ehptrs %code = load i32* %ehrec %matches = icmp eq i32 %code, i32 u0xC0000094 %matches.i32 = zext i1 %matches to i32 ret i32 %matches.i32 } define i1 zeroext @safe_div(i32 %n, i32 %d, i32* %r) { %rr = invoke i32 @normal_div(i32 %n, i32 %d) to label %normal unwind to label %lpad normal: store i32 %rr, i32* %r ret i1 1 lpad: %ehvals = landingpad {i8*, i32} personality i32 (...)* @__C_specific_handler catch i8* bitcast (i32 (i8*, i8*)* @filter to i8*) %ehptr = extractvalue {i8*, i32} %ehvals, i32 0 %sel = extractvalue {i8*, i32} %ehvals, i32 1 %filter_sel = call i32 @llvm.eh.seh.typeid.for(i8* bitcast (i32 (i8*, i8*)* @filter to i8*)) %matches = icmp eq i32 %sel, %filter_sel br i1 %matches, label %eh.except, label %eh.resume eh.except: ret i1 false eh.resume: resume } Reviewers: rjmccall, rsmith, majnemer Differential Revision: http://reviews.llvm.org/D5607 llvm-svn: 226760
* [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-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "DebugInfo: Generalize debug info location handling" and related commitsDavid Blaikie2015-01-091-1/+3
| | | | | | | | | | | | 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
* Reapply "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-301-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+3
| | | | | | | | | 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-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+3
| | | | | | | | | 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-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Use nullptr to silence -Wsentinel when self-hosting on WindowsReid Kleckner2014-12-011-3/+3
| | | | | | | | | | | Richard rejected my Sema change to interpret an integer literal zero in a varargs context as a null pointer, so -Wsentinel sees an integer literal zero and fires off a warning. Only CodeGen currently knows that it promotes integer literal zeroes in this context to pointer size on Windows. I didn't want to teach -Wsentinel about that compatibility hack. Therefore, I'm migrating to C++11 nullptr. llvm-svn: 223079
OpenPOWER on IntegriCloud