https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Andrew Downing from comment #15) > This is all kind of besides the point anyway though, because gcc is handling > everything ok except for std::launder. std::launder is only supposed to be > an optimization barrier, but it's causing the opposite problem. Here, > std::launder is preventing an optimization that shouldn't be taking place > from NOT taking place. I've been looking at gcc's code for a while and have > gotten as far as seeing that the use of std::launder is preventing > dse_classify_store() in tree-ssa-dse.c from seeing the relationship between > double d = 3.14159; and _6 here. > > // this is right before the tree-dse3 pass (I disabled some passes to > prevent constant propagation) > f1 () > { > long unsigned int u; > double d; > long unsigned int * _6; > > <bb 2> [local count: 1073741824]: > > // this line is removed by tree-dse3 > d = 3.14158999999999988261834005243144929409027099609375e+0; > > _6 = .LAUNDER (&d); > u_3 = MEM[(uint64_t *)_6]; > d ={v} {CLOBBER}; > return u_3; > > } > > If the implementation of std::launder in gcc simply disallows optimization > passes from seeing through it, I think that is a mistake. std::launder being > an optimization barrier means disallowing checks that enable an optimization > from seeing through it as well as allowing checks that disable an > optimization from seeing through it. Note that when you elide .LAUNDER nothing really changes in GCC other than when seeing these kind of must alias of a definition and a use GCC chooses to do-what-I-mean and allow type-punning. So I don't think the .LAUNDER implementation has an issue - of course I never understood the point of std::launder in the first place, but ...