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

Dale Johannesen dalej at apple.com
Tue Jan 27 10:13:48 PST 2009


On Jan 27, 2009, at 4:47 AMPST, Duncan Sands wrote:

> Hi Dale,
>
>> Fix g++.apple/blocks-in_structors.c on Darwin.
>> This allows a null "root" in initialize_chains,
>> and removes a mysterious llvm assert in
>> convert_all_function_calls.  Both situtations
>> seem to occur legitimately in this example, and
>> nothing in the testsuite breaks.
>
> this assertion is not really mysterious.

Well, it had no comments, no pointer to a bug it fixed, and no test  
case....

> 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?   
It's misspelled in the checkin message above, should be block- 
in_structors.C .




More information about the llvm-commits mailing list