On Thu, Mar 7, 2019 at 7:20 PM Martin Sebor <[email protected]> wrote:
>
> On 3/4/19 6:17 AM, Richard Biener wrote:
> > On Mon, Mar 4, 2019 at 1:23 PM Jakub Jelinek <[email protected]> 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
