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.guent...@gmail.com> wrote:
>
> On Thu, Mar 7, 2019 at 7:20 PM Martin Sebor <mse...@gmail.com> wrote:
> >
> > On 3/4/19 6:17 AM, Richard Biener wrote:
> > > On Mon, Mar 4, 2019 at 1:23 PM Jakub Jelinek <ja...@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
