On Mon, Mar 4, 2019 at 12:16 AM Jeff Law <l...@redhat.com> wrote: > > On 3/3/19 4:06 PM, Patrick Palka wrote: > > Hi everyone, > > > > I am very interested in working on GCC as part of GSoC this year. A few > > years > > ago I was a somewhat active code contributor[1] and unfortunately my > > contributing waned once I went back to school, but I'm excited to > > potentially > > have the opportunity to work on GCC again this summer. My contributions > > were > > mainly to the C++ frontend and to the middle end, and I've been thinking > > about > > potential projects in these areas of the compiler. Here are some project > > ideas > > related to parts of the compiler that I've worked on in the past: > > > > * Extend VRP to track unions of intervals > > (inspired by comment #2 of PR72443 [2]) > > Value ranges tracked by VRP currently are represented as an interval > > or > > its complement: [a,b] and ~[a,b]. A natural extension of this is > > to support unions of intervals, e.g. [a,b]U[c,d]. Such an extension > > would make VRP more powerful and at the same time would subsume > > anti-ranges, potentially making the code less complex overall. > You should get in contact with Aldy and Andrew. I believe their work > already subsumes everything you've mentioned here.
I'm not so sure so work on this would definitely be appreciated. > > > > * Make TREE_NO_WARNING more fine-grained > > (inspired by comment #7 of PR74762 [3]) > > TREE_NO_WARNING is currently used as a catch-all marker that inhibits > > all > > warnings related to the marked expression. The problem with this is > > that > > if some warning routine sets the flag for its own purpose, > > then that later may inhibit another unrelated warning from firing, > > see for > > example PR74762. Implementing a more fine-grained mechanism for > > inhibiting particular warnings would eliminate such issues. > Might be interesting. You'd probably need to discuss the details further. I guess an implementation could use TREE_NO_WARNING (or gimple_no_warning_p) as indicator that there's out-of-bad detail information which could be stored as a map keyed off either a location or a tree or gimple *. > > > > * Make -Wmaybe-uninitialized more robust > > (Inspired by the recent thread to move -Wmaybe-uninitialized to > > -Wextra [4]) > > Right now the pass generates too many false-positives, and hopefully > > that > > can be fixed somewhat. > > I think a distinction could be made between the following two > > scenarios in > > which a false-positive warning is emitted: > > 1. the pass incorrectly proves that there exists an execution path > > that > > results in VAR being used uninitialized due to a deficiency in > > the > > implementation, or > > 2. the pass gives up on exhaustively verifying that all execution > > paths > > use VAR initialized (e.g. because there are too many paths to > > check). > > The MAX_NUM_CHAINS, MAX_CHAIN_LEN, etc constants currently > > control > > when this happens. > > I'd guess that a significant fraction of false-positives occur due to > > the > > second case, so maybe it would be worthwhile to allow the user to > > suppress > > warnings of this second type by specifying a warning level argument, > > e.g. > > -Wmaybe-uninitialized=1|2. > > Still, false-positives are generated in the first case too, see e.g. > > PR61112. These can be fixed by improving the pass to understand such > > control flow. > I'd suggest you look at my proposal from 2005 if you want to improve > some of this stuff. > > You might also look at the proposal to distinguish between simple > scalars that are SSA_NAMEs and the addressable/aggregate cases. > > In general I'm not a fan of extending the predicate analysis as-is in > tree-ssa-uninit.c. I'd first like to see it broken into an independent > analysis module. The analysis it does has applications for other > warnings and optimizations. Uninit warnings would just be a client of > hte generic analysis pass. > > I'd love a way to annotate paths (or subpaths, or ssa-names) for cases > where the threaders identify a jump threading path, but don't actually > optimize it (often because it's a cold path or to avoid code bloat > problems). THese unexecutable paths that we leave in the CFG are often > a source of false positives when folks use -O1, -Os and profile directed > optimizations. Bodik has some thoughts in this space, but I haven't > really looked to see how feasible they are in the real world. > > > > > * Bug fixing in the C++ frontend / general C++ frontend improvements > > There are 100s of open PRs about the C++ frontend, and the goal here > > would just be to resolve as many as one can over the summer. > Bugfixing is always good :-) > > jeff
