On Tue, 2021-06-08 at 21:20 +0530, Ankur Saini wrote: > > > > On 01-Jun-2021, at 6:38 PM, David Malcolm <dmalc...@redhat.com> > > wrote: > >
[...snip...] > > Maybe it's best to have an > > account on the GCC compile farm for this: > > https://gcc.gnu.org/wiki/CompileFarm > > IIRC you already have such an account. It might be worth trying > > out a > > full bootstrap and testsuite run on one of the powerful machines in > > the > > farm. I tend to use "screen" in case my ssh connection drops > > during > > through a build, so that losing the ssh connection doesn't kill the > > build. > > I tried this, and it’s awesome :D , I was able to complete the either > bootstrap build on one of the powerful machine there with almost > similar time to that of what my laptop takes to build with bootstrap > disabled. Great. [...snip...] > > > - it might be good to create a personal branch on the gcc git > > repository that you can push your work to. I'm in two minds about > > this, in that ideally you'd just commit your work to trunk once > > each > > patch is approved, but maybe it's good to have a public place as a > > backup of the "under development" stuff? Also, at some point we > > want > > you to be pushing changes to the trunk, so we'll want your account > > to > > be able to do that. > > I already did that when I was fiddling around with the source code > and track my changes seperately Is there a URL for your branch? > > > > If you're *really* eager to start, you might want to look at > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546 > > This is a case where the analyzer "sees" a call through a function > > pointer, and, despite figuring out what the function pointer > > actually > > points to, entirely fails to properly handle the call, since the > > > supergraph and engine.cc code is looking at the static callgraph, > > and > > needs work to handle such calls through function pointers. I > > started > > debugging this a couple of weeks ago, and realized it has a *lot* > > of > > similarities to the vtable case, so thought I might leave it so you > > can > > have a go at it once the project starts properly. > > yes, looking at exploded graph, the analyzer is not able to > understand the call to function “noReturn()” when called via a > function pointer ( noReturnPtr.0_1 ("<source>”); ) at all. I would be > looking into it and will report back as soon as I find something > useful. The issue is that the analyzer currently divides calls into (a) calls where GCC's middle-end "knows" which function is called, and thus the call site has a cgraph_node. (b) calls where GCC's middle-end doesn't "know" which function is called. The analyzer handles (a) by building call and return edges in the supergraph, and processing them, and (b) with an "unknown call" handler, which conservatively sets lots of state to "unknown" to handle the effects of an arbitrary call, and where the call doesn't get its own exploded_edge. In this bug we have a variant of (b), let's call it (c): GCC's middle- end doesn't know which function is called, but the analyzer's region_model *does* know at a particular exploded_node. I expect this kind of thing will also arise for virtual function calls. So I think you should look at supergraph.cc at where it handles calls; I think we need to update how it handles (b), so that it can handle the (c) cases, probably by splitting supernodes at all call sites, rather than just those with cgraph_edges, and then creating exploded_edges (with custom edge info) for calls where the analyzer "figured out" what the function pointer was in the region_model, even if there wasn't a cgraph_node. Does that make sense? Or you could attack the problem from the other direction, by looking at what GCC generates for a vfunc call, and seeing if you can get the region_model to "figure out" what the function pointer is at a particular exploded_node. > > also, should I prefer discussing about this bug here( gcc mailing > list) or on the bugzilla itself ? Either way works for me. Maybe on this list? (given that this feels like a design question) Hope this is helpful Dave
