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