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 ...
