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.
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.
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
