This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Merge results as of 2003-05-06


In message <wvlk7d26t7n.fsf@prospero.boston.redhat.com>, Jason Merrill writes:
 >On Tue, 06 May 2003 22:24:46 -0600, law@redhat.com wrote:
 >
 >> In message <20030507032001.GA5056@tornado.toronto.redhat.com>, Diego Novill
 >o wr
 >> ites:
 >>  >-------------------------------------------------------------------------
 >----
 >>  >20030506/gcc.sum:
 >>  >-------------------------------------------------------------------------
 >----
 >>  >FAIL: gcc.c-torture/execute/20011024-1.c compilation
 >>  >FAIL: gcc.c-torture/execute/980526-1.c compilation
 >>  >FAIL: gcc.misc-tests/bprob-2.c compilation
 >>  >	 
 >>  >    These have been introduced by the new remove_useless_stmts_and_vars
 >>  >    In the case of 20011024-1.c, we are removing the
 >>  >    FUNCTION_DECL for abort, which causes
 >>  >    dwarf2out:add_abstract_origin_attribute to get very confused.
 >>  >    I haven't looked at the other two, but they show the same
 >>  >    error and are fixed if I undo the change.
 >> Interestingly enough none of these fail before the merge, even with the
 >> empty statement removal code.  I don't see how my code could effect these
 >> given the restrictions currently imposed on the empty statement removal
 >> code.
 >>
 >> When/how precisely was the FUNCTION_DECL removed?!?
 >
 >The FUNCTION_DECL isn't removed.  The problem is that
 >remove_useless_stmts_and_vars is removing the BIND_EXPR for the inlined
 >function, which means the block is never expanded, so reorder_blocks throws
 >it away.  But if we don't see that block, dwarf2out doesn't know that we're
 >in an inlined function, and things break down.
 >
 >We should probably limit ourselves to discarding BIND_EXPRs with empty
 >bodies.
Funny -- you should see the message I posted just a couple minutes ago :-)

The solution is to not eliminate the toplevel BIND_EXPR for an inlined
function.  It's not terribly hard to detect, in fact, I've got code here
to handle it :-)

We can't eliminate BIND_EXPRs with empty bodies unless they also have no
variables (see the thread regarding variables being used outside their
scope :-)


Jeff



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]