On Tue, Apr 2, 2019 at 1:43 AM Patrick Palka <ppalka...@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.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?
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
