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


> > 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...
> 
> It worked on Linux/ia32 and Linux/ia64. Only on Linux/x86-64,
> BLOCK_VARS (ext_block) got changed. I can try to find it out.

Weird. Figuring out what is going on here would probably be good idea...
> 
> > > +  /* Ask the back end to emit functions and variables that are
> > > +     enqueued.   These emissions may be needed for correct debug
> > > +     information.  See PR 21828.  The right fix may be to call
> > > +     check_global_declarations after cgraph_optimize.  But it doesn't
> > > +     work on gcc 4.0 branch without backporting varpool fixes from
> > > +     mainline.  */
> > > +  cgraph_varpool_assemble_pending_decls ();
> > 
> > This would result in outputing only the variables that are either
> > public or referenced by public variables.  It is necesarry to compile
> > the functions to discover variables referenced by code so I guess flags
> > will still be wrong for debug info.
> 
> It seems to work for me. The similar code is in cp_finish_file in
> cp/decl2.c on 4.0 branch. That is calling
> cgraph_varpool_assemble_pending_decls after wrapup_global_declarations. 

C++ use it only in non-unit-at-a-time mode and it cares the function
bodies to be compiled too.
Things probably should break when you create static variable referenced
only by function body and compile in unit-at-a-time mode.
> 
> > What precisely is preventing check_global_declarations being done
> > afterwards?
> 
> When I applied the mainline patch to 4.0,
> 
> const char *progname;
> 
> in errors.c was emitted as undefined, instead of common, by stage1/cc1.
> I guess this patch
> 
> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02545.html

Yeah, this patch changes quite a lot here, but in general things should
work after reordering on 4.0 too.
One case I can think of is scenario where check_global_declarations
outputs debug info about progname that causes the variable to be output
by varpool, but since the progname is global variable it should be
output in any case..

If this code wasn't so twisty, but I never managed to cleanup the
frontend backend interaction here...

Honza

> may help.
> 
> 
> H.J.


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