On Tue, Feb 01, 2022 at 05:18:57AM +0000, Richard Sandiford wrote: > I agree that changing the wording doesn't solve the whole problem, > but I think it does solve something. At the moment, we're effectively > asking each individual user to be aware of the context above, to know what > meaning is being attached to the present tense. Making the message more > equivocal would at least suggest that the compiler doesn't “know”. The compiler *does* know (in this case), but only for one internal copy of the code. The warning message (which could be an error in this case, the code replaced with a trap: a dest or source that does not point at an object is undefined behaviour, for memcpy). But the error message suggests that this happens on *every* execution of the memcpy. Which is wrong, misleading, the cause of all the confusion here. > It's not the pass's “fault” that it can't tell how closely the IL > it sees matches the original code. But it is GCC's “fault” as a whole, > not the user's, and I think that's what matters here. Yeah. > > What I think is needed here is to mention the conditions > > under which the invalid statement is executed. With that, we should > > be able to print the same context as what the static analyzer prints: > I agree this would be better, but I don't think it should hold back > tweaks to the error messages in the meantime. (And if the tracing > was an optional feature, we'd still want wording that makes sense > when the feature is turned off.) Exactly. It shouldn't be all that hard to steer the user towards discovering what is wrong with his code, instead of causing the user to think GCC is wrong again. > I realise this is rehashing an old discussion, sorry. But it seems > like it's a discussion that gets rehashed precisely because it's > about an issue that users keep hitting. Agreed, this needs to be fixed. The bigger issue is communication, the way diagnostic messages are phrased, not the analysis itself :-) Segher
