GSoC Project Ideas

GSoC Project Ideas

[Patrick Palka]

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

Re: GSoC Project Ideas

[Jeff Law]

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.



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


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

Re: GSoC Project Ideas

[Richard Biener]

On Mon, Mar 4, 2019 at 12:16 AM Jeff Law <law@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

Re: GSoC Project Ideas

[Jakub Jelinek]

On Mon, Mar 04, 2019 at 01:13:29PM +0100, Richard Biener wrote:
> > >   * 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 *.

I guess on tree or gimple * is better, there would need to be some hook for
copy_node/gimple_copy that would add the info for the new copy as well if
the TREE_NO_WARNING or gimple_no_warning_p bit was set.  Plus there could be
some purging of this on the side information, e.g.  once code is handed over
from the FE to the middle-end (maybe do that only at free_lang_data time),
for any warnings that are FE only there is no need to keep records in the on
the side mapping that have info about those FE warnings only, as later on
the FE warnings will not be reported anymore.
The implementation could be e.g. a hash map from tree/gimple * (pointers) to
bitmaps of warning numbers, with some hash table to ensure that the same
bitmap is used for all the spots that need to have the same set of warnings
disabled.

	Jakub

Re: GSoC Project Ideas

[Richard Biener]

On Mon, Mar 4, 2019 at 1:23 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Mon, Mar 04, 2019 at 01:13:29PM +0100, Richard Biener wrote:
> > > >   * 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 *.
>
> I guess on tree or gimple * is better, there would need to be some hook for
> copy_node/gimple_copy that would add the info for the new copy as well if
> the TREE_NO_WARNING or gimple_no_warning_p bit was set.  Plus there could be
> some purging of this on the side information, e.g.  once code is handed over
> from the FE to the middle-end (maybe do that only at free_lang_data time),
> for any warnings that are FE only there is no need to keep records in the on
> the side mapping that have info about those FE warnings only, as later on
> the FE warnings will not be reported anymore.
> The implementation could be e.g. a hash map from tree/gimple * (pointers) to
> bitmaps of warning numbers, with some hash table to ensure that the same
> bitmap is used for all the spots that need to have the same set of warnings
> disabled.

A possibly related project is to "defer" output of diagnostics until we know
the stmt/expression we emit it for survived dead code elimination.  Here there's
the question what to key the diagnostic off and how to move it (that is, detect
if the code causing it really fully went dead).

Richard.

>         Jakub

Re: GSoC Project Ideas

[Martin Sebor]

On 3/4/19 6:17 AM, Richard Biener wrote:
> On Mon, Mar 4, 2019 at 1:23 PM Jakub Jelinek <jakub@redhat.com> wrote:
>>
>> On Mon, Mar 04, 2019 at 01:13:29PM +0100, Richard Biener wrote:
>>>>>    * 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 *.
>>
>> I guess on tree or gimple * is better, there would need to be some hook for
>> copy_node/gimple_copy that would add the info for the new copy as well if
>> the TREE_NO_WARNING or gimple_no_warning_p bit was set.  Plus there could be
>> some purging of this on the side information, e.g.  once code is handed over
>> from the FE to the middle-end (maybe do that only at free_lang_data time),
>> for any warnings that are FE only there is no need to keep records in the on
>> the side mapping that have info about those FE warnings only, as later on
>> the FE warnings will not be reported anymore.
>> The implementation could be e.g. a hash map from tree/gimple * (pointers) to
>> bitmaps of warning numbers, with some hash table to ensure that the same
>> bitmap is used for all the spots that need to have the same set of warnings
>> disabled.
> 
> A possibly related project is to "defer" output of diagnostics until we know
> the stmt/expression we emit it for survived dead code elimination.  Here there's
> the question what to key the diagnostic off and how to move it (that is, detect
> if the code causing it really fully went dead).

Another (maybe only remotely related) aspect of this project might
be getting #pragma GCC diagnostic to work reliably with middle-end
warnings emitted for inlined code.  That it doesn't work is one of
the frustrations for users who run into false positives with "late"
warnings like -Wstringop-overflow or -Wformat-overflow.

I'm sure there are bugs that track this but here's a test case
involving -Warray-bounds:

   int a[3];

   int f (int i)
   {
     return a[i];
   }

   #pragma GCC diagnostic push
   #pragma GCC diagnostic ignored "-Warray-bounds"
   int g (void)
   {
     return f (7);   // expect no -Warray-bounds
   }
   #pragma GCC diagnostic pop

   int h (void)
   {
     return f (7);   // expect -Warray-bounds
   }

Martin

Re: GSoC Project Ideas

[Richard Biener]

On Thu, Mar 7, 2019 at 7:20 PM Martin Sebor <msebor@gmail.com> wrote:
>
> On 3/4/19 6:17 AM, Richard Biener wrote:
> > On Mon, Mar 4, 2019 at 1:23 PM Jakub Jelinek <jakub@redhat.com> wrote:
> >>
> >> On Mon, Mar 04, 2019 at 01:13:29PM +0100, Richard Biener wrote:
> >>>>>    * 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 *.
> >>
> >> I guess on tree or gimple * is better, there would need to be some hook for
> >> copy_node/gimple_copy that would add the info for the new copy as well if
> >> the TREE_NO_WARNING or gimple_no_warning_p bit was set.  Plus there could be
> >> some purging of this on the side information, e.g.  once code is handed over
> >> from the FE to the middle-end (maybe do that only at free_lang_data time),
> >> for any warnings that are FE only there is no need to keep records in the on
> >> the side mapping that have info about those FE warnings only, as later on
> >> the FE warnings will not be reported anymore.
> >> The implementation could be e.g. a hash map from tree/gimple * (pointers) to
> >> bitmaps of warning numbers, with some hash table to ensure that the same
> >> bitmap is used for all the spots that need to have the same set of warnings
> >> disabled.
> >
> > A possibly related project is to "defer" output of diagnostics until we know
> > the stmt/expression we emit it for survived dead code elimination.  Here there's
> > the question what to key the diagnostic off and how to move it (that is, detect
> > if the code causing it really fully went dead).
>
> Another (maybe only remotely related) aspect of this project might
> be getting #pragma GCC diagnostic to work reliably with middle-end
> warnings emitted for inlined code.  That it doesn't work is one of
> the frustrations for users who run into false positives with "late"
> warnings like -Wstringop-overflow or -Wformat-overflow.

A similar issue is they are not carried along from compile-time to
LTO link time.  I'm not even sure how they are attached to anything
right now ... certainly not in DECL_FUNCTION_SPECIFIC_OPTIMIZATION.

> I'm sure there are bugs that track this but here's a test case
> involving -Warray-bounds:
>
>    int a[3];
>
>    int f (int i)
>    {
>      return a[i];
>    }
>
>    #pragma GCC diagnostic push
>    #pragma GCC diagnostic ignored "-Warray-bounds"
>    int g (void)
>    {
>      return f (7);   // expect no -Warray-bounds
>    }
>    #pragma GCC diagnostic pop
>
>    int h (void)
>    {
>      return f (7);   // expect -Warray-bounds
>    }
>
> Martin

Re: GSoC Project Ideas

[Patrick Palka]

Hi Richard, Jakub and Martin,

First of all I'm sorry for the very late reply, and I will be more
punctual with my replies from now on.

On Fri, Mar 8, 2019 at 4:35 AM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Thu, Mar 7, 2019 at 7:20 PM Martin Sebor <msebor@gmail.com> wrote:
> >
> > On 3/4/19 6:17 AM, Richard Biener wrote:
> > > On Mon, Mar 4, 2019 at 1:23 PM Jakub Jelinek <jakub@redhat.com> wrote:
> > >>
> > >> On Mon, Mar 04, 2019 at 01:13:29PM +0100, Richard Biener wrote:
> > >>>>>    * 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 *.
> > >>
> > >> I guess on tree or gimple * is better, there would need to be some hook for
> > >> copy_node/gimple_copy that would add the info for the new copy as well if
> > >> the TREE_NO_WARNING or gimple_no_warning_p bit was set.  Plus there could be
> > >> some purging of this on the side information, e.g.  once code is handed over
> > >> from the FE to the middle-end (maybe do that only at free_lang_data time),
> > >> for any warnings that are FE only there is no need to keep records in the on
> > >> the side mapping that have info about those FE warnings only, as later on
> > >> the FE warnings will not be reported anymore.
> > >> The implementation could be e.g. a hash map from tree/gimple * (pointers) to
> > >> bitmaps of warning numbers, with some hash table to ensure that the same
> > >> bitmap is used for all the spots that need to have the same set of warnings
> > >> disabled.

This design makes a lot of sense, thank you for this!

> > >
> > > A possibly related project is to "defer" output of diagnostics until we know
> > > the stmt/expression we emit it for survived dead code elimination.  Here there's
> > > the question what to key the diagnostic off and how to move it (that is, detect
> > > if the code causing it really fully went dead).

Interesting.  Which diagnostics would you have in mind to defer in this way?

> >
> > Another (maybe only remotely related) aspect of this project might
> > be getting #pragma GCC diagnostic to work reliably with middle-end
> > warnings emitted for inlined code.  That it doesn't work is one of
> > the frustrations for users who run into false positives with "late"
> > warnings like -Wstringop-overflow or -Wformat-overflow.

Thank you Martin for bringing this up!

>
> A similar issue is they are not carried along from compile-time to
> LTO link time.  I'm not even sure how they are attached to anything
> right now ... certainly not in DECL_FUNCTION_SPECIFIC_OPTIMIZATION.

This is good to know too.

I know that there is only a week left to submit a proposal, but I am
thinking of a project proposal that can be summarized in one line as
"Improving the diagnostics infrastructure of GCC," which combines the
original proposal about a finer-grained
TREE_NO_WARNING/gimple_no_warning mechanism along with Richard's and
Martin's ideas of preserving diagnostic pragmas after inlining and for
LTO link time, and maybe Richard's idea of being able to defer
diagnostics until we know for sure that the code in question survives
DCE.  Would such a proposal be well-defined and tractable enough for
GSoC?  If so, would anyone volunteer to be a mentor for this project?

Regards,
Patrick


>
> > I'm sure there are bugs that track this but here's a test case
> > involving -Warray-bounds:
> >
> >    int a[3];
> >
> >    int f (int i)
> >    {
> >      return a[i];
> >    }
> >
> >    #pragma GCC diagnostic push
> >    #pragma GCC diagnostic ignored "-Warray-bounds"
> >    int g (void)
> >    {
> >      return f (7);   // expect no -Warray-bounds
> >    }
> >    #pragma GCC diagnostic pop
> >
> >    int h (void)
> >    {
> >      return f (7);   // expect -Warray-bounds
> >    }
> >
> > Martin

Re: GSoC Project Ideas

[Richard Biener]

On Tue, Apr 2, 2019 at 1:43 AM Patrick Palka <ppalka007@gmail.com> wrote:
>
> Hi Richard, Jakub and Martin,
>
> First of all I'm sorry for the very late reply, and I will be more
> punctual with my replies from now on.
>
> On Fri, Mar 8, 2019 at 4:35 AM Richard Biener
> <richard.guenther@gmail.com> wrote:
> >
> > On Thu, Mar 7, 2019 at 7:20 PM Martin Sebor <msebor@gmail.com> wrote:
> > >
> > > On 3/4/19 6:17 AM, Richard Biener wrote:
> > > > On Mon, Mar 4, 2019 at 1:23 PM Jakub Jelinek <jakub@redhat.com> wrote:
> > > >>
> > > >> On Mon, Mar 04, 2019 at 01:13:29PM +0100, Richard Biener wrote:
> > > >>>>>    * 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 *.
> > > >>
> > > >> I guess on tree or gimple * is better, there would need to be some hook for
> > > >> copy_node/gimple_copy that would add the info for the new copy as well if
> > > >> the TREE_NO_WARNING or gimple_no_warning_p bit was set.  Plus there could be
> > > >> some purging of this on the side information, e.g.  once code is handed over
> > > >> from the FE to the middle-end (maybe do that only at free_lang_data time),
> > > >> for any warnings that are FE only there is no need to keep records in the on
> > > >> the side mapping that have info about those FE warnings only, as later on
> > > >> the FE warnings will not be reported anymore.
> > > >> The implementation could be e.g. a hash map from tree/gimple * (pointers) to
> > > >> bitmaps of warning numbers, with some hash table to ensure that the same
> > > >> bitmap is used for all the spots that need to have the same set of warnings
> > > >> disabled.
>
> This design makes a lot of sense, thank you for this!
>
> > > >
> > > > A possibly related project is to "defer" output of diagnostics until we know
> > > > the stmt/expression we emit it for survived dead code elimination.  Here there's
> > > > the question what to key the diagnostic off and how to move it (that is, detect
> > > > if the code causing it really fully went dead).
>
> Interesting.  Which diagnostics would you have in mind to defer in this way?
>
> > >
> > > Another (maybe only remotely related) aspect of this project might
> > > be getting #pragma GCC diagnostic to work reliably with middle-end
> > > warnings emitted for inlined code.  That it doesn't work is one of
> > > the frustrations for users who run into false positives with "late"
> > > warnings like -Wstringop-overflow or -Wformat-overflow.
>
> Thank you Martin for bringing this up!
>
> >
> > A similar issue is they are not carried along from compile-time to
> > LTO link time.  I'm not even sure how they are attached to anything
> > right now ... certainly not in DECL_FUNCTION_SPECIFIC_OPTIMIZATION.
>
> This is good to know too.
>
> I know that there is only a week left to submit a proposal, but I am
> thinking of a project proposal that can be summarized in one line as
> "Improving the diagnostics infrastructure of GCC," which combines the
> original proposal about a finer-grained
> TREE_NO_WARNING/gimple_no_warning mechanism along with Richard's and
> Martin's ideas of preserving diagnostic pragmas after inlining and for
> LTO link time, and maybe Richard's idea of being able to defer
> diagnostics until we know for sure that the code in question survives
> DCE.  Would such a proposal be well-defined and tractable enough for
> GSoC?  If so, would anyone volunteer to be a mentor for this project?

I think there are only vague ideas for TREE_NO_WARNING/defering right now
and no concrete ones for the issue of sub-function granular #pragma diagnostics
(that means also inlining).

Improving how LTO handles [late] warnings might be interesting given that could
be implemented function-granular (where we already have function-granular
optimization options).  But I'm not sure my statement quoted from above
is even correct -- IIRC #pragma GCC diagnostic does work for late
warnings on a function-granular level (does it?), so the LTO issue might be
simply missed streaming (or does it work after all?).

Richard.

> Regards,
> Patrick
>
>
> >
> > > I'm sure there are bugs that track this but here's a test case
> > > involving -Warray-bounds:
> > >
> > >    int a[3];
> > >
> > >    int f (int i)
> > >    {
> > >      return a[i];
> > >    }
> > >
> > >    #pragma GCC diagnostic push
> > >    #pragma GCC diagnostic ignored "-Warray-bounds"
> > >    int g (void)
> > >    {
> > >      return f (7);   // expect no -Warray-bounds
> > >    }
> > >    #pragma GCC diagnostic pop
> > >
> > >    int h (void)
> > >    {
> > >      return f (7);   // expect -Warray-bounds
> > >    }
> > >
> > > Martin

Re: GSoC Project Ideas

[Joseph Myers]

On Mon, 1 Apr 2019, Patrick Palka wrote:

> > > > A possibly related project is to "defer" output of diagnostics 
> > > > until we know the stmt/expression we emit it for survived dead 
> > > > code elimination.  Here there's the question what to key the 
> > > > diagnostic off and how to move it (that is, detect if the code 
> > > > causing it really fully went dead).
> 
> Interesting.  Which diagnostics would you have in mind to defer in this way?

For example, where the C front end does folding early for diagnostics such 
as -Wsign-compare, and then makes its own limited attempt to see if e.g. 
an expression of signed type must have nonnegative value.  It would be 
appropriate for the diagnostic to be done later (so more powerful 
optimizations can be used to tell if the value in fact is in a range 
meaning the diagnostic is not needed, or if it's in dead code), and that 
would reduce the number of places the C front end needs to call 
c_fully_fold (with a following call to c_wrap_maybe_const to avoid 
repeated recursive folding of the same trees).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GSoC Project Ideas

[Martin Sebor]

On 4/17/19 8:57 AM, Joseph Myers wrote:
> On Mon, 1 Apr 2019, Patrick Palka wrote:
> 
>>>>> A possibly related project is to "defer" output of diagnostics
>>>>> until we know the stmt/expression we emit it for survived dead
>>>>> code elimination.  Here there's the question what to key the
>>>>> diagnostic off and how to move it (that is, detect if the code
>>>>> causing it really fully went dead).
>>
>> Interesting.  Which diagnostics would you have in mind to defer in this way?
> 
> For example, where the C front end does folding early for diagnostics such
> as -Wsign-compare, and then makes its own limited attempt to see if e.g.
> an expression of signed type must have nonnegative value.  It would be
> appropriate for the diagnostic to be done later (so more powerful
> optimizations can be used to tell if the value in fact is in a range
> meaning the diagnostic is not needed, or if it's in dead code), and that
> would reduce the number of places the C front end needs to call
> c_fully_fold (with a following call to c_wrap_maybe_const to avoid
> repeated recursive folding of the same trees).

Besides the front-ends, diagnostics currently issued during folding
(-Wrestrict, -Wstringop-overflow, and -Wstringop-truncation) would
also benefit from the same approach.  For instance, the warning below
could be avoided.  (The warning has to be issued from the folder in
order to detect the problem before the strncpy call is turned into
memcpy or MEM_REF.)

Martin

$ cat a.c && gcc -O -S -Wall -Wextra -fdump-tree-gimple=/dev/stdout 
-o/dev/stdout a.c
void f (char *d, unsigned i)
{
   if (i & (1LU << 34))
    __builtin_strncpy (d, "123", 3);
}
	.file	"a.c"
f (char * d, unsigned int i)
{
   _1 = (long unsigned int) i;
   _2 = _1 & 17179869184;
   if (_2 != 0) goto <D.1910>; else goto <D.1911>;
   <D.1910>:
   __builtin_strncpy (d, "123", 3);
   <D.1911>:
}


a.c: In function ‘f’:
a.c:4:4: warning: ‘__builtin_strncpy’ output truncated before 
terminating nul copying 3 bytes from a string of the same length 
[-Wstringop-truncation]
     4 |    __builtin_strncpy (d, "123", 3);
       |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	.text
	.globl	f
	.type	f, @function
f:
.LFB0:
	.cfi_startproc
	ret
	.cfi_endproc
.LFE0:
	.size	f, .-f
	.ident	"GCC: (GNU) 9.0.1 20190417 (experimental)"
	.section	.note.GNU-stack,"",@progbits

Re: GSoC Project Ideas

[Patrick Palka]

On Sun, Mar 3, 2019 at 5:16 PM Jeff Law <law@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.
>
>
>
> >
> >   * 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.
>
>
> >
> >   * 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.

Hi Jeff,

I read your proposal from 2005 (I think the main part is
https://gcc.gnu.org/ml/gcc/2005-11/msg00040.html) and I wonder how
your position has changed since the uninit pass has been made
predicate-aware.

I see what you mean about breaking the predicate analysis out from the
rest of the uninit pass.  Would that be a good start of a project on
improving the uninit pass?  If so, I have in mind a project proposal
that would consist of:

1. breaking out the predicate analysis from the rest of the uninit pass,
2. enhancing the uninit pass to detect uninitialized uses of memory
operands, e.g. PR 19430)  (I think this could be doable by reusing
most of the existing pass that operates on SSA_NAMEs?  I am not
exactly sure what the complications are),
3. enhancing the predicate analysis to fix genuine bugs like PR 61112,
4. adding noisiness levels (ideally non-numeric ones, as Eric
suggested) to -Wmaybe-uninitialized that controls
whether to warn about uses which the uninit pass gives up on.

Would this be a reasonable project for GSoC?  If so, would anyone be
willing to mentor it?

I also posted a proposal template for the aforementioned
TREE_NO_WARNING project, and I wonder which project would be more
appropriate for GSoC if one had to choose.

>
> >
> >   * 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 :-)

Would such a general bug-fixing project be appropriate for GSoC?  If
so, I can certainly submit a proposal, if anyone is willing to mentor
it.

Regards,
Patrick

>
> jeff

Re: GSoC Project Ideas

[Jeff Law]

On 4/1/19 6:40 PM, Patrick Palka wrote:
> On Sun, Mar 3, 2019 at 5:16 PM Jeff Law <law@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.
>>
>>
>>
>>>
>>>   * 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.
>>
>>
>>>
>>>   * 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.
> 
> Hi Jeff,
> 
> I read your proposal from 2005 (I think the main part is
> https://gcc.gnu.org/ml/gcc/2005-11/msg00040.html) and I wonder how
> your position has changed since the uninit pass has been made
> predicate-aware.
I don't think it's changed that much, if at all.  The predicate stuff
has all the same issues that we have with other analysis/optimizations
that intersect with this space.

By that I mean the predicate analysis code is still quite sensitive to
the shape of the CFG -- seemingly unrelated changes earlier in the
pipeline can easily change the shape of the CFG and confuse the
predicate analysis code resulting in false positives.

Even so I think there's a lot of interesting value in the predicate
analysis bits, hence my desire to break it into an analysis engine and a
client (uninit warnings).  We can then re-use the analysis engine elsewhere.


> 
> I see what you mean about breaking the predicate analysis out from the
> rest of the uninit pass.  Would that be a good start of a project on
> improving the uninit pass?  If so, I have in mind a project proposal
> that would consist of:
> 
> 1. breaking out the predicate analysis from the rest of the uninit pass,
Right.  I haven't dug deeply here, but at a high level marking an
infeasible path detected by predicate analysis seems like what we're
shooting for.  The client then uses those markings to either suppress
warnings or optimize the path.

Other passes could conceivably mark infeasible paths as well.  The
threader for example does discover some infeasible paths, but leaves
them in the IL if they're too expensive to remove.

> 2. enhancing the uninit pass to detect uninitialized uses of memory
> operands, e.g. PR 19430)  (I think this could be doable by reusing
> most of the existing pass that operates on SSA_NAMEs?  I am not
> exactly sure what the complications are),
There's some bits for this already done by Richi and others.  I think
one of the things we want to do is distinguish between simple scalars vs
aggregates/addressables for uninit warnings.

I haven't dug into the problems we have with addressables/aggregates,
but I suspect that aliasing likely gets in the way often of doing a good
job.

I don't want to creep the scope, but this class of problems interacts
with DSE and SRA tightly.  ISTM (and others) that there's commonality in
the analysis necessary to do a good job for these problems.  So it's
probably worth digging into what we do in DSE and SRA and the aliasing
code and see what can be re-used/enhanced.





> 3. enhancing the predicate analysis to fix genuine bugs like PR 61112,
WIthout digging in deeply, this looks like either a failure to thread
jumps or a case where jump threading decided it was too costly to
optimize.  I'd start there before worrying much about the uninit bits
for 61112.

Also note that some of of Andrew/Aldy's work is putting in
infrastructure to address other jump threading limitations exposed by
various BZs.  Many of the BZs related to false positive uninit warnings
for scalars I have state on.  I'm happy to pass that state along.

> 4. adding noisiness levels (ideally non-numeric ones, as Eric
> suggested) to -Wmaybe-uninitialized that controls
> whether to warn about uses which the uninit pass gives up on.
Yes.

> 
> Would this be a reasonable project for GSoC?  If so, would anyone be
> willing to mentor it?
Maybe -- we (Red Hat) have had problems in the past with GSoC results,
but I think that you've already shown a stronger understanding of GCC
internals with prior GSoC work.  So I may be able to push mgt here to
get some bandwith for you.

> 
> I also posted a proposal template for the aforementioned
> TREE_NO_WARNING project, and I wonder which project would be more
> appropriate for GSoC if one had to choose.
I think either probably works for GSoC -- as long as you can carve up
milestones as I think either could potentially go beyond the scope
typically covered by GSoC.

> 
>>
>>>
>>>   * 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 :-)
> 
> Would such a general bug-fixing project be appropriate for GSoC?  If
> so, I can certainly submit a proposal, if anyone is willing to mentor
> it.
I think so, especially if there's a cluster of related bugs (like the
uninit stuff we've touched on).

Jeff

Re: GSoC Project Ideas

[P J P]

On Monday, 4 March, 2019, 4:37:07 AM IST, Patrick Palka <ppalka007@gmail.com> wrote: 
>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.
>
>  * Extend VRP to track unions of intervals
>    (inspired by comment #2 of PR72443 [2])
>
>  * Make TREE_NO_WARNING more fine-grained
>    (inspired by comment #7 of PR74762 [3])
>
>  * Make -Wmaybe-uninitialized more robust
>      (Inspired by the recent thread to move -Wmaybe-uninitialized to -Wextra [4])
>
>  * 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.

Interesting!

>Would any of these ideas work as a GSoC project?

  -> https://gcc.gnu.org/ml/gcc/2019-03/msg00016.html
  -> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210


Could this RFE be considered for a GSoC project?

Thank you.
---
  -P J P
http://feedmug.com

Re: GSoC Project Ideas

[Eric Gallager]

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
>

GSoC project ideas

[Maxim Kuvyrkov]

Hi,

GCC has applied as a mentoring organization to GSoC 2014, and we need to update Project Ideas page: http://gcc.gnu.org/wiki/SummerOfCode .  Ideas is where GSoC starts, and this is what captures attention and imagination of prospective students (and future developers!) of GCC.

If you have an idea for a student project -- post it at http://gcc.gnu.org/wiki/SummerOfCode .  If you can't easily edit the wiki directly, feel free to send your ideas to me directly or as a reply to this thread, I will add them to the wiki.

You don't have to commit to be a mentor for an idea that you post.  We will worry about finding mentors once a student expresses interest in a particular idea.

You don't have to be an active GCC developer to post an idea.  If you are an experienced GCC user and you wanted all your life a feature X in GCC -- post an idea about it.

If you are a prospective GSoC student -- then we definitely want to hear your ideas.

We need the ideas page all updated and ready by the end of February (couple of weeks left).  Student applications period opens on March 10th, and keep in mind that students would need to meditate on the various projects/ideas/choices for a week or so.

For GSoC 2014 timeline see https://www.google-melange.com/gsoc/events/google/gsoc2014 .

Thank you,

--
Maxim Kuvyrkov
www.linaro.org