https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #40 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 15 Jun 2020, richard-gccbugzilla at metafoo dot co.uk wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349 > > --- Comment #37 from Richard Smith <richard-gccbugzilla at metafoo dot co.uk> > --- > (In reply to Richard Biener from comment #36) > > The main issue I see is that this differing expectations of C and C++ are > > impossible to get correct at the same time. > > That is a rather bold claim. I think you can satisfy both rule sets by using > the C++ rule even in C. It is conservatively correct to discard the effective > / > dynamic type when you see a memcpy, and the C++ semantics require you to do > so. > > The C semantics also appear to require the same thing, if you cannot track the > destination back to either an object with a declared type or to a heap > allocation; as described in comment#35, GCC gets this wrong and presumably > miscompiles C code in some cases as a result. I very much would like to see such an example! The current GCC rule is quite simple - every store to memory alters the dynamic type of the stored to object to that of the store. Up to now we've had more success with that model than any other we tried before. > It seems to me that all you're allowed to do within the bounds of conformance > is: > > #1 if you can track the destination back to an object with declared type in C > code, then use its type as the effective type of the result > > #2 if you can track the destination back to a heap allocation in C code, then > copy the effective type from source to destination > > #3 otherwise (in either C or C++) erase the effective type of the destination > > (#1 and #3 will presumably result in memcpy being replaced by some operation > that updates the effective type, rather than being eliminated entirely.) Indeed. Such "operation that updates the effective type" would have come handy in a few cases already, but we do not have it right now and given past experience with variants of it (bad one, obviously) I'm not too keen of re-introducing it. That GCC elideds the memcpy roundtrip is (in the above model where every store alters the dynamic type) a bug - the memcpy internally actually discards the dynamic type info. The option of having to preserve that roundtrip isn't very appealing though. We've went to that way for cases where we now cannot remove a "redundant" store (a store with the same bit pattern but different effective type). Bottom line is I wouldn't hold my breath getting this fixed on the GCC side. Like with the partial object re-use and aggregate assignment case the C++ FE will have the option disabling type-based alias-analysis completely for some objects (but I can't see how that helps with the case referenced here).
