https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 18 Feb 2020, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745 > > --- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> --- > That's why I asked "What language relies on this?" > > But regardless of what language might have even looser rules than C/C++ in > this > area, it would seem like a rather unfortunate design limitation for GCC not to > be able to analyze and optimize C/C++ code as well as other compilers can > because it supports languages others don't (LLVM supports most of the > languages > GCC does). > > What would it take to get GCC to handle this case? Changing the front-end to > implicitly declare p restrict? (That would only work in a small subset of > cases and would be wrong in many more.) I guess it would be sth like marking decls with a new DECL_FIXED_DYNAMIC_TYPE flag? Note that TBAA works with a very small set of implementation building blocks and often final semantics are the outcome of the need to fulfil certain properties. For example before C++17(?) came along there was no real written consent as to how do struct { int kind; char data[64]; } x; and new (x.data) T - that's one reason we have the middle-end semantics we have (code used to do that and we had to make it work). Now we have TYPE_TYPELESS_STORAGE on the data member (which is implementation-wise an even bigger hammer!) but only the C++ FE sets that. But there's still people doing effectively the same in C where there's no standards blessed way - QOI tells me we should still support them. So effectively the middle-end doesn't know the dynamic type of an object unless it can derive it by seeing a store to the object or a load from the object (a load only constraints the dynamic type, it doesn't fixate it). The consequences are that we can't optimize some of the "obvious" cases but as you say yourself it's hard to be conservatively correct but also most optimal and we can't be wrong in a _single_ case. We arrived at the current scheme as a result of getting _many_ cases wrong with a load of hacks in place and no real idea of a middle-end memory model. I fixed that back in time and now all stores possibly change the dynamic type of the underlying object.
