https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jan Žižka from comment #18) > Created attachment 53617 [details] > Third reproducer failing with 9baee6181b4e427e0b5ba417e51424c15858dce7 > > I did cherry-pick 9baee6181b4e427e0b5ba417e51424c15858dce7 on top of > 5edf02ed2b6de024f83a023d046a6a18f645bc83 and gcc 12 and I confirm that the > second reproducer works with this. But unfortunately our production code > still fails. > > Sorry that I cannot provide better more reliable reproducer, but our > production code is complex and I try to bump it to smallest snippet which > still fails. I can try to refactor our production code somehow to remove all > proprietary stuff but that might take some time. > > I have created new reproducer, this time it fails both with boost::optional > and with std::optional. In the reproducer I have commented lines which will > cause the warning to disappear when removed. There is additional int in the > structure which needs to be there and also the assignment needs to be > repeated in the loop. Ah, thanks - a testcase that breaks with std::optional is good to have. Aha, the new trick fails because Value numbering stmt = _271 = MEM[(struct _Optional_payload_base *)&externals + 48B]._M_engaged; Skipping possible redundant definition MEM[(struct _Optional_payload_base *)&externals + 48B]._M_engaged = 0; Cannot skip second possible redundant definition MEM[(struct _Optional_payload_base *)&externals + 48B]._M_engaged = 0; Setting value number of _271 to _271 (changed) of course a simple change can handle this - stupid me of not thinking of that!
