https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 7 Oct 2014, hubicka at ucw dot cz wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 > > --- Comment #22 from Jan Hubicka <hubicka at ucw dot cz> --- > We can also put warning attribute into gimple call. I like that better. We can easily add a GF_CALL_WARN / GF_CALL_ERROR flag, but the question is where to put the warning string... the issue with this bugreport is that it might not be on the decl (because the decl is now replaced with one with/without the attribute). Maybe if we always "merge" the warning attributes then the call flag tells us whether to ignore it or not ... Thus for this particular bug (bogus warning) just adding the flag as a requirement to emit the warning/error would be enough. We may still lose warnings/errors if the wrong decl is picked for a GF_CALL_WARN call though. Yeah, now the idea of adding a generic annotation pointer to gimple stmts will pop up again ... of course I don't like that very much. OTOH we had the idea of avoiding warnings from the middle-end for dead code by queuing warnings to emit on stmts and only emit them if the stmt is still live at a certain point during the compilation. All that said - what about going with the simple GF_CALL_WARN_OR_ERROR flag to avoid the false "positives"?
