This is the mail archive of the gcc-patches@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: PATCH: [4.0/4.1 Regression] debug info omitted for uninitialized variables


> On Tue, Jul 05, 2005 at 09:12:11PM +0200, Jan Hubicka wrote:
> > > On Tue, Jul 05, 2005 at 08:43:22AM +0200, Jan Hubicka wrote:
> > > > 
> > > > > to fix a serious 4.0/4.1 regression:
> > > > > 
> > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21828
> > > > > 
> > > > > where debug info is omitted for uninitialized variables. It seems that
> > > > > check_global_declarations does the wrong thing on uninitialized
> > > > > variables.
> > > > 
> > > > Hmm, there are quite few nasty bits here.  I think you are right in the
> > > > bug audit trail that check_global_declarations should be reordred after
> > > > cgraph finalization as it checks TREE_ASM_WRITTEN flag that is clearly
> > > > not set in a way it expects.
> > > > 
> > > 
> > > There are 2 patches here, one for mainline and the other for gcc 4.0.
> > > But I am afraid that the patch for mainline may be time consuming. Also
> > > I am not sure if it handles "BLOCK_VARS (ext_block)" correctly. On
> > > Linux/x86-64, BLOCK_VARS (ext_block) changes after cgraph_optimize. I
> > 
> > This sounds rather surpsing (ie there is nothing in cgraph code dealing
> > with the ext_block or BLOCK_VARS so if it worked originally, it should
> > still work, but perhaps something gets changed during gimplification...
> 
> I got
> 
> Breakpoint 3, c_write_global_declarations ()
>     at /net/gnu-3/export/gnu/src/gcc/gcc/gcc/c-decl.c:7575
> 7575          ext_block_vec = c_write_global_declarations_1
> (ext_block_vars);
> (gdb) p ext_block->block.vars
> $2 = 0x2a97b77270
> (gdb) p ext_block_vars
> $3 = 0x2a97b77270
> (gdb) p &ext_block->block.vars
> $4 = (tree *) 0x2a9cdb9c68
> (gdb) watch *(long *) 0x2a9cdb9c68
> Hardware watchpoint 4: *(long *) 183020264552
> (gdb) c
> Continuing.
> Hardware watchpoint 4: *(long *) 183020264552
> 
> Old value = 182934008432
> New value = 0
> 0x0000003838870f27 in memset () from /lib64/tls/libc.so.6
> (gdb) bt
> 
> It looks like the memory pointed to by ext_block got freed and reused
> somehow. Is that normal? Does rewrite_blocks do that on purpose? If it

It looks like GGC bug. Probably ext_block is not properly marked by GTY.
I am still traveling till 10th, but I can debug it on next monday if the
problem can wait next few days.

Concerning the C++ and unit-at-a-time, you are right that 4.0 already
dropped non-unit-at-a-time but that hunk of code actually look slike
leftover of that (I removed it while working on the varpool reorg later
in mainline).  This is all just much more ugly than it needs to be :(

Also notice that now mainline has two places to call into debug info for
static vars - one in check_global_vars other in assemble_pending_decls
for local scope static vars.  This probably can be cleaned up somehow
too (perhaps all the debug hooks can be called by cgraph when outputting
the variables but I am not quite sure if order depends on something)

Honza

> is true, how should check_global_declarations be called properly after
> cgraph_optimize?
> 
> 
> H.J.


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