[llvm-commits] [llvm-gcc-4.2] r63087 - /llvm-gcc-4.2/trunk/gcc/tree-nested.c

[Dale Johannesen]

On Jan 27, 2009, at 10:26 AMPST, Duncan Sands wrote:

> Hi Dale,
>>
>>> It is here
>>> because I had to add a bunch of code to fix a long
>>> standing tree-nested bug in which nested function bodies
>>> and callers have different opinions as to whether
>>> the function takes a static chain parameter or not.
>>> This doesn't matter much for gcc because the parameter
>>> is passed out of line, but it is rather horrible for
>>> llvm-gcc because it is added as an explicit parameter
>>> to the function.  I never got round to pushing this
>>> upstream, but I really should.  Anyway, the assertion
>>> is checking that a nested subroutine (the root->outer
>>> check ensures that this is a nested subroutine) takes
>>> an extra parameter for passing variables belonging to
>>> the parent (the "static chain") if and only if either
>>> it itself accesses a variable belonging to its parent
>>> (in which case root->chain_field is not null) or one
>>> of its child nested subroutines does (in which case
>>> root->chain_decl is not null).
>>>
>>>> -      gcc_assert (!root->outer ||
>>>> -                  DECL_NO_STATIC_CHAIN (root->context) ==
>>>> -                  !(root->chain_decl || root->chain_field));
>>>
>>> If the assertion is failing, it seems to me that something
>>> bad is going on.
>>
>> You may be right, or this may be another case where ObjC isn't doing
>> what you expect (which you would probably consider abuse).  I
>> concluded it was the latter, but  you seem to understand what this
>> code is doing better than I, maybe you could look at the testcase?
>
> I will.  Sadly I do understand the horror that is tree-nested, at
> least I used to.  I had to in order to implement support for nested
> functions in llvm-gcc :( :)

OK.  I've also got a question in the guy who implemented the "blocks"  
stuff in ObjC, who fortunately is still here:)  He can probably  
clarify what ObjC is doing.