https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
--- Comment #13 from Giuseppe D'Angelo <dangelog at gmail dot com> --- Hi, (In reply to Martin Sebor from comment #12) > So in general, the distinction between the two cases can only be made when > it can be discerned from the IL, and the IL doesn't always preserve the > conditional nature of the problem statement. So every warning must always > be viewed as a "maybe" kind of a warning. It will never be a sure a thing, > either at the scope of individual functions, and certainly not with inlining > or function cloning. I think there's been a misunderstanding. Apologies if I created confusion, let me try and reset the conversation: I perfectly understand if, in the context of this particular warning (or any other similar middle-end warning), it is very hard, or currently impossible, or even always impossible to distinguish between the "maybe" case and the "certain" case. Without such a distinction available or possible, I'm also OK with raising false positives. Therefore, in relation to this aspect of the original submission (the code raising a false positive warning), I'm perfectly fine at marking the request of not triggering the warning altogether as out of scope / won't fix / etc. On other hand, I was not OK with the idea that the *warning message* should keep saying that "there *is* an overflow", in a positive indicative mood. All I'd really ask there would be to reword the message in order to say something like "there *may be* an overflow" instead. It might seem like a trivial/useless change for someone who knows how the middle-end works and where such warnings come from, but it would bring a lot of clarity to end-users (to me, at least) if any warning message would clearly indicate whether it may be a false positive. And that could be achieved by simply adding "may" to the warning messages in question. Does this make sense? Thanks,
