https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745
--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 27 Feb 2020, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745 > > --- Comment #11 from Martin Sebor <msebor at gcc dot gnu.org> --- > Regarding the DECL_FIXED_DYNAMIC_TYPE flag: it seems like in C every DECL > would > have it set, but in C++ none could (because placement new can change the > dynamic type of decls), and so GCC would not be able to optimize the example > in > that language even though there the read via *p means that p cannot alias d. > > If what's keeping GCC from optimizing the code is the fact that the middle-end > doesn't distinguish placement new from plain assignment, i.e., that it can't > tell that the original source didn't look like this: > > double d; > > void f (long *p) > { > long i = *p; > new (&d) double (3); > *p = i; > } > > wouldn't the solution be to keep placement new around in some form and teach > the middle-end how to work with it? We had this and it didn't work (OK, we only kept it in GIMPLE but not RTL which is of course a non-starter). Feel free to come up with a solid proposal and implementation. What would eventually work (but again not for the specific example TU) is an IPA pass constraining the dynamic type of global variables. But then that's then a natural extension of our lack of a flow-sensitive [IPA] points-to analysis.
