On Wed, Apr 29, 2015 at 3:01 AM, Aldy Hernandez <al...@redhat.com> wrote: > [This is actually for the debug-early branch, but I figured I'd avoid the > [debug-early] subject line to alert others of the upcoming change. Actually, > I should've adapted this and submitted it to mainline, but considering I > should be submitting the debug-early work "Real Soon Now" (tm), I don't want > to get side-tracked.] > > This is one of those changes that Richi likes-- moving stuff out of the > front-ends and into generic land... > > The check_global_declarations checks were failing in the branch because > mainline depends on both, trees being present, and tree bits being set late > in the compilation, sometimes as late as RTL (in the case of > TREE_SYMBOL_REFERENCED). The front-ends were making a list of interesting > globals, and feeding them to check_global_declarations() to issue certain > use without define (and vice versa) warnings. > > Instead of caching these globals from the front-end all the way to the > back-end, I redesigned it to check global declarations generically, in a > language agnostic way, while using symtab/cgraph to determine usage (instead > of TREE_USED and other magic bits that weren't as accurate or in certain > cases, available). > > With this patch we fix a slew of regressions on the debug-early branch, and > we find a lot more legitimate warnings. I had to adjust a lot of tests, > because we're being much more aggressive. IMO, this is good. Interestingly > enough, I even found the following in gengtype.c: > > +/* ?? Why are we keeping this? Is this actually used anywhere? */ > +static void ATTRIBUTE_UNUSED > output_typename (outf_p of, const_type_p t) > > The reason mainline was not picking this up was because output_typename() > was calling itself, thus the infrastructure assumed it was used. By the > way, can I remove this unused symbol instead of papering over the problem > with ATTRIBUTE_UNUSED? > > The attached patch was tested with GCC and GDB. It only has one regression, > which I've asked Jason to look at to determine if it is a false positive or > not: g++.dg/torture/pr46383.C. > > Gentlemen, is this an approach you can bless? Don't worry about fully > reviewing it (unless you want to-- no complaints here), I just want to make > sure it's something I can commit to the branch and continue onto other > regressions. You will all get a chance to crucify the entire branch real > soon :).
Yeah, the approach looks sane. Richard. > Thanks. > Aldy
