On 3/3/19, Patrick Palka <ppalka...@gmail.com> 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. > > * 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. > > * 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.
Instead of adding numeric levels to -Wmaybe-uninitialized, I'd prefer to have different named flags for finer granularity. For example, clang has -Wsometimes-uninitialized and -Wconditional-uninitialized: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00225.html > 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. > > * 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. You're missing a zero; that should be thousands, not hundreds... ;-) > > Would any of these ideas work as a GSoC project? > > Regards, > Patrick Palka > > [1]: https://gcc.gnu.org/git/?p=gcc.git;a=search;s=ppalka;st=author > [2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72443#c2 > [3]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74762#c7 > [4]: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00020.html >