Re: GSoC Project Ideas

[Eric Gallager <egall at gwmail dot gwu dot edu>]

On 3/3/19, Patrick Palka <ppalka007@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
>