https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108243
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P2 --- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> --- I'm not sure if this is supposed to be fixed yet. For the comment#2 testcase I now get <bb 2> [local count: 1073741824]: _1 = __atomic_load_1 (&_ZGVZ4mainE3foo, 2); if (_1 == 0) goto <bb 4>; [33.00%] else goto <bb 3>; [67.00%] <bb 3> [local count: 956811341]: goto <bb 6>; [100.00%] <bb 4> [local count: 354334800]: _2 = __cxa_guard_acquire (&_ZGVZ4mainE3foo); if (_2 != 0) goto <bb 5>; [33.00%] else goto <bb 3>; [67.00%] <bb 5> [local count: 116930483]: MEM[(struct string_view *)&foo] ={v} {CLOBBER}; MEM[(struct string_view *)&foo].str = "bar"; MEM[(struct string_view *)&foo].len = 3; __cxa_guard_release (&_ZGVZ4mainE3foo); <bb 6> [local count: 1073741824]: _9 = foo.len; _8 = (int) _9; return _8; so we fail to CSE foo.len because __cxa_guard_release possibly clobbers it (it's global memory). Note the clobbering is necessary to prevent code motion across the lock primitives. Note that __cxa_guard_release also prevents removing the .str initialization since only the .len member is ever inspected. As noted static initialization would improve this quite a bit.