[cfe-commits] r60989 - in /cfe/trunk/lib/CodeGen: CGDecl.cpp CGExprScalar.cpp

[Daniel Dunbar]

On Mon, Dec 15, 2008 at 8:47 AM, Douglas Gregor <dgregor at apple.com> wrote:
>
> On Dec 13, 2008, at 6:07 PM, Eli Friedman wrote:
>
>> On Sat, Dec 13, 2008 at 4:40 PM, Neil Booth <neil at daikokuya.co.uk>
>> wrote:
>>> Eli Friedman wrote:-
>>>
>>>> On Sat, Dec 13, 2008 at 10:58 AM, Chris Lattner <sabre at nondot.org>
>>>> wrote:
>>>>> Author: lattner
>>>>> Date: Sat Dec 13 12:58:59 2008
>>>>> New Revision: 60989
>>>>>
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=60989&view=rev
>>>>> Log:
>>>>> disable Anders' recent VLA patch, this fixes PR3209.
>>>>
>>>> I looked into this a bit... the crash is an issue with the
>>>> stacksave/stackrestore code.  Roughly, the block with the VLA has a
>>>> return statement in it; then, the stackrestore gets inserted into an
>>>> undefined location.  This can be worked around with a
>>>> EnsureInsertPoint(), but the issue remains: we need to ensure that
>>>> control flow passes through an appropriate stackrestore before it
>>>> exits the block.  And we simply don't have the infrastructure in
>>>> place
>>>> to do that at the moment.
>>>>
>>>> Has anyone thought about how to implement this?  It looks like
>>>> something similar is implemented for ObjC exception handling, but
>>>> I'm
>>>> not sure how well the current approach will generalize...

I think the basic approach is the same, but as you say probably needs
some generalization. I think the basic mechanism  we need to provide
is the ability to push a "scope" and guarantee that exits from that
scope are forwarded through some extra basic block which can do
cleanup.

I'd prefer to finish Obj-C exception support prior to generalizing though.

>>> Do you intend to represent these control flow requirements explicitly
>>> in the AST, or have AST clients have to understand the semantics?
>>> Like implicit casts being made explicit, I'm in favour of the former.

I agree we do not want clients to have to interpret the semantics.
However, unlike implicit casts, it is less clear how to integrate this
information into the ASTs; the semantics cannot be expressed in the
language. Did you have a scheme in mind?

>> Mmmm... it would definitely make things easier if the AST tracked
>> which scopes any given jump exits, like maybe a map from  jump
>> statements to the outermost scope which they jump out of.  I guess we
>> really need something like this even for Sema: we still haven't
>> implemented diagnostics for jumping into the scope of a VLA.
>
>
> We'll need similar information to determine whether we're jumping past
> declarations with initialization in C++.

Yup. We need similar information for checking for jumps into special
Objective-C blocks (exceptions, @synchronized). We also could benefit
greatly from having such information just to finish Obj-C exception
support, because when we encounter a break or continue or goto we need
to determine which scopes to exit, and we currently have no easy way
to do this.

If Sema is going to need this information already then we should
definitely find a way to save it, I think. Its probably useful at this
point to think about whether the AST should have any information about
the scopes in it; I believe this is something Ted could make use of in
the static analyzer, and this would be a natural place for storing
some of this additional information.

 - Daniel