Re: GSoC Project Ideas

[Martin Sebor <msebor at gmail dot com>]

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