On Mon, Jun 10, 2013 at 3:36 PM, Adrian Prantl <[email protected]> wrote: > > On Jun 10, 2013, at 11:38 AM, David Blaikie <[email protected]> wrote: >> With this (or Eric's) change do we get the right (same as (or >> justified if different) GCC) number/placement of scopes/variables for: >> >> if (x) >> a(); >> else >> b(); >> >> if (int x = ...) >> a(); >> else >> b(); >> >> if (int x = ...) { >> int y = ...; >> a(); >> } else { >> int z = ...; >> } >> >> (in theory 'x' should be in-scope across both the if and the else, but >> we probably don't bother creating a scope if there's no variable in >> that scope - and just create one for the if/else bodies... but not >> sure) > I’m not sure if I understand what you are trying to say... > > For the code above we generate a > (unsure) > > DW_TAG_lexical scope > DW_TAG_variable (x) > > DW_TAG_lexical scope > DW_TAG_variable (x) > DW_TAG_lexical scope > DW_TAG_variable (y) > DW_TAG_lexical scope > DW_TAG_variable (z) > > I’m not sure how to interpret the x at the beginning of the function.
They were intended to be 3 separate examples - the first wasn't too interesting (the 'x' being implied declaration outside that scope), except in that we could potentially emit lexical_scopes for instruction ranges even when they don't contain variables, but that's probably just pure DWARF bloat there's no reason to bother with. > The only difference between GCC and clang I can spot is that GCC puts the > entire function into a DW_TAG_lexical scope, but I don’t think that this is > strictly necessary. *nod* (interestingly we used to always emit that scope but GCC doesn't emit it in C mode - we now don't emit it in C or C++ (based on changes I made) which gives slightly better behavior from GDB (you can refer to local variables and labels at the top scope with func::var (for watches, jumps, etc) which you can't do once there's 'var' is within a scope nested further within the function scope) > Does that answer the question? Yes, thank you - hopefully these are tested somewhere, if not they could be tested alongside the case you've fixed just to make sure we're covering the the broad range of cases like this. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
